From p2psip-bounces@ietf.org Thu Feb 08 15:17:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFFi6-0000Hs-DT; Thu, 08 Feb 2007 15:17:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFFi4-0000Hn-QL for p2psip@ietf.org; Thu, 08 Feb 2007 15:17:36 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFFi1-0000jZ-IC for p2psip@ietf.org; Thu, 08 Feb 2007 15:17:36 -0500 Received: by ug-out-1314.google.com with SMTP id 72so515731ugd for ; Thu, 08 Feb 2007 12:17:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=EhE22dqGIs8A9O6YNLE8OLpXAPwxLjq9Lfwk0tNvLjb+Ht8hgyRcY9Iz21ahiomE7eZkNFMbbBuxOZBQHVt/AfecuUaqCdSBpcsq1JSJiBkXPNmsKtAG0BIZAh9Hvn3sXprQjMNhpLLp1gkOZ1388IP/MVnqPFU9lKA8BUIk9Ts= Received: by 10.78.183.15 with SMTP id g15mr1042333huf.1170965848023; Thu, 08 Feb 2007 12:17:28 -0800 (PST) Received: by 10.49.33.11 with HTTP; Thu, 8 Feb 2007 12:17:27 -0800 (PST) Message-ID: <8b2769930702081217y20bb2f54y8f947ba16df2b6ea@mail.gmail.com> Date: Thu, 8 Feb 2007 15:17:27 -0500 From: "David A. Bryan" To: P2PSIP MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 37e7421dffd12813 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: p2psip@ietf.org Subject: [P2PSIP] IMPORTANT: New mailing list at IETF X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Folks: Now that we are officially a WG, we have an IETF email list, and I'd like to start moving discussion over to that list. For the next week or so, you might want to consider cross posting messages to both lists. Thanks! David New IETF mailing list information: General Discussion: p2psip@ietf.org Subscribe at: https://www1.ietf.org/mailman/listinfo/p2psip Archive at: http://www1.ietf.org/mail-archive/web/p2psip/current _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Feb 08 15:29:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFFt8-0004Hl-Lv; Thu, 08 Feb 2007 15:29:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFFt7-0004Hf-CZ for p2psip@ietf.org; Thu, 08 Feb 2007 15:29:01 -0500 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFFt6-0003FF-3B for p2psip@ietf.org; Thu, 08 Feb 2007 15:29:01 -0500 Received: by wr-out-0506.google.com with SMTP id 67so687586wri for ; Thu, 08 Feb 2007 12:28:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Nk2ctu3V0kXHV380en2zR3BksMvYL/4F7u3MEbgUmrnc/fFwnI7W+WFHk/oIhgQWBV0WvbMD8hYz6rBoFB69ubrEJa+Uh06Cvl1rtOjRdE08g31XrOGk3r9zt8dK7gGO5goQh8CVs4Lw/CCWSO0L/kQDnbeXB34t5AQZUWD/zrI= Received: by 10.114.75.1 with SMTP id x1mr4838769waa.1170966124894; Thu, 08 Feb 2007 12:22:04 -0800 (PST) Received: by 10.114.112.8 with HTTP; Thu, 8 Feb 2007 12:22:04 -0800 (PST) Message-ID: <618e24240702081222u643f7a18me4968ffb26740478@mail.gmail.com> Date: Thu, 8 Feb 2007 21:22:04 +0100 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: p2psip@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: [P2PSIP] Re: Welcome to the "P2PSIP" mailing list X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Folks, did the discussion start? Congratulations for the new WG! Victor Pascual 2007/2/8, p2psip-request@ietf.org : > Welcome to the P2PSIP@ietf.org mailing list! This email is to let you > know that you have been subscribed to the P2PSIP mailing list at > ietf.org. > > This list is for the discussions related to the development, > clarification and implementation of the Peer-to-Peer SIP protocol. > > > > To post to this list, send your email to: > > p2psip@ietf.org > > General information about the mailing list is at: > > https://www1.ietf.org/mailman/listinfo/p2psip > > ********************************************************************** > > Note Well > > Any submission to the IETF intended by the Contributor for publication > as all or part of an IETF Internet-Draft or RFC and any statement made > within the context of an IETF activity is considered an "IETF > Contribution". Such statements include oral statements in IETF > sessions, as well as written and electronic communications made at any > time or place, which are addressed to: > > - the IETF plenary session, > - any IETF working group or portion thereof, > - the IESG, or any member thereof on behalf of the IESG, > - the IAB or any member thereof on behalf of the IAB, > - any IETF mailing list, including the IETF list itself, any > working group or design team list, or any other list > functioning under IETF auspices, > - the RFC Editor or the Internet-Drafts function > > All IETF Contributions are subject to the rules of RFC 3978 (updated > by RFC 4748) and RFC 3979. > > Statements made outside of an IETF session, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not IETF Contributions in the context > of this notice. > > Please consult RFC 3978 (and RFC 4748) for details. > > A participant in any IETF activity is deemed to accept all IETF rules > of process, as documented in Best Current Practices RFCs and IESG > Statements. > > A participant in any IETF activity acknowledges that written, audio > and video records of meetings may be made and may be available to the > public. > > *************************************************************************= ****** > > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your word, etc.), visit your subscription > page at: > > https://www1.ietf.org/mailman/options/p2psip/victor.pascual.avila%40gma= il.com > > > You can also make such adjustments via email by sending a message to: > > P2PSIP-request@ietf.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your word to change your options (including changing the > word, itself) or to unsubscribe. It is: > > carapan69 > > Normally, Mailman will remind you of your ietf.org mailing list words > once every month, although you can disable this if you prefer. This > reminder will also include instructions on how to unsubscribe or > change your account options. There is also a button on your options > page that will email your current word to you. > --=20 Victor Pascual =C1vila mail:victor.pascual.avila@gmail.com sip:victor.pascual@iptel.org fon user: 223364 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Feb 08 15:55:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFGIc-0003c2-Vs; Thu, 08 Feb 2007 15:55:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFGIb-0003bu-Jg for p2psip@ietf.org; Thu, 08 Feb 2007 15:55:21 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFGIU-0002Ut-D2 for p2psip@ietf.org; Thu, 08 Feb 2007 15:55:21 -0500 Received: by nf-out-0910.google.com with SMTP id l36so986229nfa for ; Thu, 08 Feb 2007 12:55:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=WsOV2jnuNJRtb350Y6TJ0RCo424jbEbgg2chpqvm9EgI8gHugwW9Lw+5otjVpfvqOithx7maonGkYKbOUlQtpBuCUqdpBeDRgeZw2HWNCn8v4djVLRl/1ICzkD9cDjKEQ91iCsyzY32+3xKr1DZny6a+2SkFOUH3prpEQ9oA98w= Received: by 10.49.27.11 with SMTP id e11mr879828nfj.1170968111451; Thu, 08 Feb 2007 12:55:11 -0800 (PST) Received: by 10.49.56.7 with HTTP; Thu, 8 Feb 2007 12:55:11 -0800 (PST) Message-ID: <9dc4a1670702081255o5ce62acbm32b095eadd08c4c1@mail.gmail.com> Date: Thu, 8 Feb 2007 15:55:11 -0500 From: EdPimentl To: "David A. Bryan" , p2psip@ietf.org In-Reply-To: <8b2769930702081217y20bb2f54y8f947ba16df2b6ea@mail.gmail.com> MIME-Version: 1.0 References: <8b2769930702081217y20bb2f54y8f947ba16df2b6ea@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [P2PSIP] Re: [p2p-sip] IMPORTANT: New mailing list at IETF X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0885284450==" Errors-To: p2psip-bounces@ietf.org --===============0885284450== Content-Type: multipart/alternative; boundary="----=_Part_32754_10953599.1170968111170" ------=_Part_32754_10953599.1170968111170 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Bryan, I have launched an opensource sourceforge p2psip project to stricly follow the IETF drafts and future rfcs. I like to schedule a few minutes with you and get your thoughts on OpenDHT, Bamboo, etc... code.. and its applicability in developing the initial IETF P2PSIP base code.. Please tell me when you have 15 min to chat Sincerely, Ed Pimentel AgileCO Founder Cell: 678.522.8511 Mail: ed[at]agileco.net Mail: edpimentel[at]gmail.com Web: http://agileco.net sip: sip:2150112@truphone.com IM: edpimentl [AOL | Jabber | Yahoo | MSN ] Voip: edpimentl [SKype | GoogleTalk ] Mobile Content Marketing/Management/Digital Delivery http://mobilecentral.ws Social Network (Private Label) http://GooGaYa.com Mobile Payment/P2P Payment http://agilepay.ws ------=_Part_32754_10953599.1170968111170 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Bryan,

I have launched an opensource sourceforge p2psip project to stricly follow the IETF drafts and future rfcs.
I like to schedule a few minutes with you and get your thoughts on OpenDHT, Bamboo, etc... code.. and its applicability in developing the initial IETF  P2PSIP base code..
Please tell me when you have 15 min to chat

Sincerely,

Ed Pimentel
AgileCO
Founder

Cell:   678.522.8511
Mail:   ed[at]agileco.net
Mail:   edpimentel[at]gmail.com
Web:     http://agileco.net
sip:    sip:2150112@truphone.com
IM:     edpimentl [AOL | Jabber | Yahoo | MSN ]
Voip:   edpimentl [SKype | GoogleTalk ]

Mobile Content Marketing/Management/Digital Delivery
http://mobilecentral.ws

Social Network (Private Label)
http://GooGaYa.com

Mobile Payment/P2P Payment
http://agilepay.ws ------=_Part_32754_10953599.1170968111170-- --===============0885284450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0885284450==-- From p2psip-bounces@ietf.org Thu Feb 08 16:32:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFGsk-0007UB-Ec; Thu, 08 Feb 2007 16:32:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFGsk-0007U6-13 for p2psip@ietf.org; Thu, 08 Feb 2007 16:32:42 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFGsh-0002s9-OW for p2psip@ietf.org; Thu, 08 Feb 2007 16:32:42 -0500 Received: by ug-out-1314.google.com with SMTP id 72so534507ugd for ; Thu, 08 Feb 2007 13:32:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=o8AVQWAgoHBidZ+uKgnzGefmUNDx11/XbpEB8R6wi5ZnXV556U8ty7zDPt+3iplzVeJfqw3B971ivgRwC5ixfjrky4XfUWZRbDbpnlRizaMnBgnaNeO/6kq+A5SI9vWXrcCg3tN9FRpzKMPJFIerM0x7Jr+ZRAIbPNz86sCPe2g= Received: by 10.67.106.3 with SMTP id i3mr4626410ugm.1170970358391; Thu, 08 Feb 2007 13:32:38 -0800 (PST) Received: by 10.49.33.11 with HTTP; Thu, 8 Feb 2007 13:32:38 -0800 (PST) Message-ID: <8b2769930702081332s634ae794lacc1fb9d14afd330@mail.gmail.com> Date: Thu, 8 Feb 2007 16:32:38 -0500 From: "David A. Bryan" To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: a8a6b31aa7a3f905 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [P2PSIP] Mailing list clarification X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dan asked if I subscribed everyone to the new list, and the answer is no. I figured there might be some zombie subscriptions on the old list that we didn't need to have on the new one, so please go and subscribe yourself to the new list. Thanks for the reminder, Dan. David _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Feb 08 17:21:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFHdk-0000ne-Ly; Thu, 08 Feb 2007 17:21:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFGhn-0000ll-NX for p2psip@ietf.org; Thu, 08 Feb 2007 16:21:23 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFGhl-0008T9-Ay for p2psip@ietf.org; Thu, 08 Feb 2007 16:21:23 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l18LLJ7U004343 for ; Thu, 8 Feb 2007 16:21:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Feb 2007 23:21:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2p-sip] IMPORTANT: New mailing list at IETF Thread-Index: AcdLvlinZVD3RgIDSwKUZ6rJWgUzFgACJXBw References: <8b2769930702081217y20bb2f54y8f947ba16df2b6ea@mail.gmail.com> From: "Romascanu, Dan \(Dan\)" To: "David A. Bryan" , "P2PSIP" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Thu, 08 Feb 2007 17:21:15 -0500 Cc: p2psip@ietf.org Subject: [P2PSIP] RE: [p2p-sip] IMPORTANT: New mailing list at IETF X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David, Did you transfer all participants from the older list to the new one or should we subscribe individually?=20 Dan =20 =20 > -----Original Message----- > From: p2p-sip-bounces@cs.columbia.edu=20 > [mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of David A. Bryan > Sent: Thursday, February 08, 2007 10:17 PM > To: P2PSIP > Cc: p2psip@ietf.org > Subject: [p2p-sip] IMPORTANT: New mailing list at IETF >=20 > Hi Folks: >=20 > Now that we are officially a WG, we have an IETF email list,=20 > and I'd like to start moving discussion over to that list. >=20 > For the next week or so, you might want to consider cross=20 > posting messages to both lists. >=20 > Thanks! >=20 > David >=20 > New IETF mailing list information: >=20 > General Discussion: p2psip@ietf.org > Subscribe at: https://www1.ietf.org/mailman/listinfo/p2psip > Archive at: http://www1.ietf.org/mail-archive/web/p2psip/current > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 14 10:58:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMWA-0004ta-7V; Wed, 14 Feb 2007 10:58:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMW9-0004rX-6I for p2psip@ietf.org; Wed, 14 Feb 2007 10:58:01 -0500 Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHMW7-0006q7-Qt for p2psip@ietf.org; Wed, 14 Feb 2007 10:58:01 -0500 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1EFvuxq015135 for ; Wed, 14 Feb 2007 10:57:57 -0500 Received: from [192.168.1.112] ([216.13.42.66]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id l1EFvtGk026309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 14 Feb 2007 10:57:57 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed To: p2psip@ietf.org From: Philip Matthews Date: Wed, 14 Feb 2007 10:58:43 -0500 X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [P2PSIP] Concepts draft respin X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Just thought I would let folks know what to expect in the next version of the Concepts draft. I am working away on the respin as time permits, and I fully plan to have it out by the deadline, but I don't think it will appear much before the deadline because of other things I have to work on (including other drafts). The major technical changes will be: 1) Addressing open issues 1 - 8. In previous e-mails, I have described these issues. 2) Adding the idea that a peer = "peer + (optional) SIP entity". This was already mentioned in the BOF in San Diego. 3) Adding the third architecture choice that a client might connect to multiple peers. Eric Rescorla suggested this in an e-mail message sent to the list shortly before the San Diego meeting. Other than these changes, I am planning to address the comments receives from various people, and go a general rewrite and clean-up. If anyone has any comments on open issues 5 - 8 that I published a few weeks ago, or has any other comments on the -03 version, this would be a good time to send them to me. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 20 11:06:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXVe-0008H8-OH; Tue, 20 Feb 2007 11:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXVc-0008G6-KC for p2psip@ietf.org; Tue, 20 Feb 2007 11:06:28 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXVb-00062Z-4F for p2psip@ietf.org; Tue, 20 Feb 2007 11:06:28 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDR00338REQ1Z@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Feb 2007 08:06:26 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDR007MEREOQU@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Feb 2007 08:06:26 -0800 (PST) Date: Tue, 20 Feb 2007 10:06:15 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Concepts draft respin To: p2psip@ietf.org Message-id: <002e01c75509$0caed700$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Philip, > Just thought I would let folks know what to expect > in the next version of the Concepts draft. I am working > away on the respin as time permits, and I fully plan to have it > out by the deadline, but I don't think it will appear much > before the deadline because of other things I have to > work on (including other drafts). > > The major technical changes will be: > 1) Addressing open issues 1 - 8. In previous e-mails, > I have described these issues. I had responded to your open issues 1-4 posting, at https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002012.html. I agreed with your proposals for 2 and 3, but pointed out that Brian Rosen had suggested a fairly different model in issue 1, at https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-December/001912.html, which we have not discussed as a working group, and that issue 4 seemed to assume that all services could be identified with a SIP URI, which is OK for SIP-based services but not for STUN, which I also hear people calling a "service". I didn't see a response, so wanted to ping you on these two comments while you were still working on the next version of the Concepts draft. Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 20 11:15:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXeb-0003VA-Q5; Tue, 20 Feb 2007 11:15:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXeZ-0003UC-Vf for p2psip@ietf.org; Tue, 20 Feb 2007 11:15:43 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXeY-0007uI-Nr for p2psip@ietf.org; Tue, 20 Feb 2007 11:15:43 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDR0034RRU61Z@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Feb 2007 08:15:42 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDR0078BRU5QU@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Feb 2007 08:15:42 -0800 (PST) Date: Tue, 20 Feb 2007 10:15:32 -0600 From: Spencer Dawkins To: P2PSIP Mailing List Message-id: <008701c7550a$5855cb40$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4553C513-0067-44FB-962A-1B864BCE2061@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [P2PSIP] Re: [p2p-sip] Concept Draft Open Issue #7: Add concept of "Admittingpeer"? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I didn't see any followup onlist for this open issue, and wanted to say that I agree with Philip's proposal. Thanks, Spencer > Open Issue #7: David Bryan and Bruce Lowekamp, > in draft-bryan-sipping-p2p-03, have introduced the concept > of an "admitting peer" as the peer that helps the "joining peer" > join the Overlay. > > In their scheme, the "joining peer" initially contacts > a "bootstrap peer". However, the bootstrap peer, rather > than doing the work to help the joining peer join the overlay, > instead immediately refers the bootstrap peer to another > peer which is better suited to help the joining peer > join the overlay. For example, in their draft, the > admitting peer is the future successor of the joining peer. > > In some work that Eric Cooper and I have been looking at recently, > we have also seen the advantage of distinguishing between > the bootstrap peer and the admitting peer. > > Note that the bootstrap peer and the admitting peer may be the same node > in some cases (in David's case, if the bootstrap peer just happens > to be the future successor of the joining peer). > > This also leads to a possible terminology changes. > First of all, the term "joining peer" as the name for the peer > that is joining the overlay. > Second, replacing the current term "peer insertion" with > "peer admission", to show that the Overlay may reject the > joining peer, if the joining peer does not have the correct > credentials to join. > > Proposal: Add the above concepts to the Concepts draft, > along with the proposed terminology changes. > > Comments? > > - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 20 11:34:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXwb-0005z5-S3; Tue, 20 Feb 2007 11:34:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXwb-0005yz-0j for p2psip@ietf.org; Tue, 20 Feb 2007 11:34:21 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXwY-0003zf-Pk for p2psip@ietf.org; Tue, 20 Feb 2007 11:34:21 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDR003R8SP21Z@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Feb 2007 08:34:14 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDR007A4SP1QU@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Feb 2007 08:34:14 -0800 (PST) Date: Tue, 20 Feb 2007 10:34:04 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Concepts draft respin To: p2psip@ietf.org Message-id: <015e01c7550c$ef311bd0$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Philip, > 3) Adding the third architecture choice that a client might > connect to multiple peers. Eric Rescorla suggested this in an e-mail > message sent to the list shortly before the San Diego meeting. Was this the posting that you're referring to? https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-October/001598.html Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 20 11:47:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJY9K-00048n-JU; Tue, 20 Feb 2007 11:47:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJY9J-00048h-TS for p2psip@ietf.org; Tue, 20 Feb 2007 11:47:29 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJY9F-0006VW-H1 for p2psip@ietf.org; Tue, 20 Feb 2007 11:47:29 -0500 Received: by ug-out-1314.google.com with SMTP id 72so853279ugd for ; Tue, 20 Feb 2007 08:47:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=cWYEgk5+pu/7RNdFPbfnW7zbMLkmwk2zIACJq8dpcMLgGsiiXtBw3/TkEohwvy+Ww4273G6eyg/BeOSdOT9ALRJ5BrHHYncV/N8d5QweRws7Qry9Is6IOX15yJ2hXxo9PRkClfMkqbYh08y1U5jgOH6s78mnur5lPcgsZekhuY4= Received: by 10.114.94.1 with SMTP id r1mr2513177wab.1171990043403; Tue, 20 Feb 2007 08:47:23 -0800 (PST) Received: by 10.114.197.10 with HTTP; Tue, 20 Feb 2007 08:47:15 -0800 (PST) Message-ID: <9dc4a1670702200847o62af8b80rdfaa08c7d0c2fc60@mail.gmail.com> Date: Tue, 20 Feb 2007 11:47:15 -0500 From: EdPimentl To: "Philip Matthews" Subject: Re: [P2PSIP] Concepts draft respin In-Reply-To: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> MIME-Version: 1.0 References: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1451270551==" Errors-To: p2psip-bounces@ietf.org --===============1451270551== Content-Type: multipart/alternative; boundary="----=_Part_50936_9344781.1171990035463" ------=_Part_50936_9344781.1171990035463 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Philip, Where are the latest comments available? -E On 2/14/07, Philip Matthews wrote: > > Just thought I would let folks know what to expect > in the next version of the Concepts draft. I am working > away on the respin as time permits, and I fully plan to have it > out by the deadline, but I don't think it will appear much > before the deadline because of other things I have to > work on (including other drafts). > > The major technical changes will be: > 1) Addressing open issues 1 - 8. In previous e-mails, > I have described these issues. > 2) Adding the idea that a peer = "peer + (optional) SIP entity". > This was already mentioned in the BOF in San Diego. > 3) Adding the third architecture choice that a client might > connect to multiple peers. Eric Rescorla suggested this in an e-mail > message sent to the list shortly before the San Diego meeting. > > > Sincerely, Ed Pimentel AgileCO Founder Mail: edpimentl[at]gmail.com sip: sip:2150112@truphone.com IM: edpimentl [AOL | Jabber | Yahoo | MSN ] Voip: edpimentl [SKype | GoogleTalk ] Mobile Content Marketing/Management/Digital Delivery http://mobilecentral.ws Mobile ( Context, Ambient, Location ) based Social Network http://TagR.mobi(apha0 Mobile Payment - P2P Payment http://agilepay.ws Sponsor of P2PSIP open source [viasip_ng] project Creating a standards base SKYPE- (open} infrastructure https://sourceforge.net/projects/viasip/ Mailing List viasip_ng@freelists.org ------=_Part_50936_9344781.1171990035463 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Philip,

Where are the latest comments available?
-E

On 2/14/07, Philip Matthews <philip_matthews@magma.ca > wrote:
Just thought I would let folks know what to expect
in the next version of the Concepts draft.  I am working
away on the respin as time permits, and I fully plan to have it
out by the deadline, but I don't think it will appear much
before the deadline because of other things I have to
work on (including other drafts).

The major technical changes will be:
1) Addressing open issues 1 - 8.  In previous e-mails,
    I have described these issues.
2) Adding the idea that a peer = "peer + (optional) SIP entity".
    This was already mentioned in the BOF in San Diego.
3) Adding the third architecture choice that a client might
    connect to multiple peers. Eric Rescorla suggested this in an e-mail
    message sent to the list shortly before the San Diego meeting.





Sincerely,

Ed Pimentel
AgileCO
Founder

Mail:   edpimentl[at]gmail.com
sip:    sip:2150112@truphone.com
IM:     edpimentl [AOL | Jabber | Yahoo | MSN ]
Voip:   edpimentl [SKype | GoogleTalk ]

Mobile Content Marketing/Management/Digital Delivery
http://mobilecentral.ws

Mobile ( Context, Ambient, Location ) based Social Network
http://TagR.mobi(apha0

Mobile Payment - P2P Payment
http://agilepay.ws

Sponsor of P2PSIP  open source [viasip_ng] project
Creating a standards base SKYPE- (open} infrastructure
https://sourceforge.net/projects/viasip/
Mailing List viasip_ng@freelists.org ------=_Part_50936_9344781.1171990035463-- --===============1451270551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1451270551==-- From p2psip-bounces@ietf.org Tue Feb 20 12:31:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJYpk-0003ih-AL; Tue, 20 Feb 2007 12:31:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJYpj-0003iV-4C for p2psip@ietf.org; Tue, 20 Feb 2007 12:31:19 -0500 Received: from mx2-7.spamtrap.magma.ca ([209.217.78.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJYpg-0001P6-Ou for p2psip@ietf.org; Tue, 20 Feb 2007 12:31:19 -0500 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx2-7.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1KHV9xs001645; Tue, 20 Feb 2007 12:31:09 -0500 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id l1KHV8O0018697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Feb 2007 12:31:09 -0500 In-Reply-To: <002e01c75509$0caed700$ad600240@china.huawei.com> References: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> <002e01c75509$0caed700$ad600240@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Concepts draft respin Date: Tue, 20 Feb 2007 12:32:08 -0500 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 20-Feb-07, at 11:06 , Spencer Dawkins wrote: > Hi, Philip, > > >> Just thought I would let folks know what to expect >> in the next version of the Concepts draft. I am working >> away on the respin as time permits, and I fully plan to have it >> out by the deadline, but I don't think it will appear much >> before the deadline because of other things I have to >> work on (including other drafts). >> >> The major technical changes will be: >> 1) Addressing open issues 1 - 8. In previous e-mails, >> I have described these issues. > > I had responded to your open issues 1-4 posting, at https:// > lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002012.html. I > agreed with your proposals for 2 and 3, but pointed out that Brian > Rosen had suggested a fairly different model in issue 1, at https:// > lists.cs.columbia.edu/pipermail/p2p-sip/2006-December/001912.html, > which we have not discussed as a working group, and that issue 4 > seemed to assume that all services could be identified with a SIP > URI, which is OK for SIP-based services but not for STUN, which I > also hear people calling a "service". > > I didn't see a response, so wanted to ping you on these two > comments while you were still working on the next version of the > Concepts draft. > I think you have swapped issues 1 and 4 in your message. Issue 1 was "Do we need a way to discover which peers offer which services?". Issue 4 was "Do clients offer services?" Brian's posting was on issue #4. As I stated in https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ 001983.html my proposal is to basically punt on this issue for now: > Open Issue #4: Can clients offer services? Or are services only offered by peers? > Summary of Mailing List Discussion: > Views were mixed. Some supported this proposal, while others did not. > Enrico suggested that we simply defer this decision by saying that > services are offered by peer or by peers and clients. > Proposal: Defer the question and adopt Enrico's proposed wording for now. I am hoping that this will satisfy everyone. Regarding issue #1. I see your point about URIs for non-SIP-based services, but I think we may be able to finesse this. We may be able to use a SIP URI to describe the service, and return one or more SIP URIs that describe the peers that offer the service, even if the service is not SIP-based. Or we may choose an entirely different way of describing services and the peers that offer them, since some people have suggested that URIs are not the right way to describe services. I will try to capture this debate in some way in the document. And, BTW, I don't expect to get to the serious writing until next Monday. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 20 12:33:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJYsB-0004fN-CC; Tue, 20 Feb 2007 12:33:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJYsA-0004fI-In for p2psip@ietf.org; Tue, 20 Feb 2007 12:33:50 -0500 Received: from mx5-4.spamtrap.magma.ca ([209.217.78.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJYs8-0001yU-87 for p2psip@ietf.org; Tue, 20 Feb 2007 12:33:50 -0500 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx5-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1KHXgqM028232; Tue, 20 Feb 2007 12:33:42 -0500 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l1KHXfBc010460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Feb 2007 12:33:42 -0500 In-Reply-To: <015e01c7550c$ef311bd0$ad600240@china.huawei.com> References: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> <015e01c7550c$ef311bd0$ad600240@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <538CF3C9-21C4-444B-AC77-D063587F9CE1@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Concepts draft respin Date: Tue, 20 Feb 2007 12:34:41 -0500 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Actually, I was referring to EKR's original posting https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-October/ 001583.html - Philip On 20-Feb-07, at 11:34 , Spencer Dawkins wrote: > Hi, Philip, > >> 3) Adding the third architecture choice that a client might >> connect to multiple peers. Eric Rescorla suggested this in an e- >> mail >> message sent to the list shortly before the San Diego meeting. > > Was this the posting that you're referring to? > > https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-October/ > 001598.html > > Thanks, > > Spencer > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 20 12:38:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJYwt-0006Aj-Nm; Tue, 20 Feb 2007 12:38:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJYws-0006Aa-MA for p2psip@ietf.org; Tue, 20 Feb 2007 12:38:42 -0500 Received: from mx1-3.spamtrap.magma.ca ([209.217.78.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJYwq-0003f8-8J for p2psip@ietf.org; Tue, 20 Feb 2007 12:38:42 -0500 Received: from mail3.magma.ca (mail3.internal.magma.ca [10.0.10.13]) by mx1-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1KHcbiX026943; Tue, 20 Feb 2007 12:38:37 -0500 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail3.magma.ca (Magma's Mail Server) with ESMTP id l1KHcZ2j009290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Feb 2007 12:38:36 -0500 In-Reply-To: <9dc4a1670702200847o62af8b80rdfaa08c7d0c2fc60@mail.gmail.com> References: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> <9dc4a1670702200847o62af8b80rdfaa08c7d0c2fc60@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <7C9FF0D1-1317-4869-ABB4-6F94C38D5966@magma.ca> From: Philip Matthews Subject: Re: [P2PSIP] Concepts draft respin Date: Tue, 20 Feb 2007 12:39:36 -0500 To: EdPimentl X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2046546453==" Errors-To: p2psip-bounces@ietf.org --===============2046546453== Content-Type: multipart/alternative; boundary=Apple-Mail-7-412447826 --Apple-Mail-7-412447826 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed If you mean the latest comments on the draft, they have been posted by various people to the mailing list. I plan to try to address all comments posted by people since the last version (-03) was posted. If you mean, where is the latest version of the draft itself, the latest version is still the -03 version of last October. I am working on some other documents this week (which are due by the earlier -00 deadline), and plan to spend all next week working on the -04 version. - Philip On 20-Feb-07, at 11:47 , EdPimentl wrote: > Hello Philip, > > Where are the latest comments available? > -E > > On 2/14/07, Philip Matthews wrote: > Just thought I would let folks know what to expect > in the next version of the Concepts draft. I am working > away on the respin as time permits, and I fully plan to have it > out by the deadline, but I don't think it will appear much > before the deadline because of other things I have to > work on (including other drafts). > > The major technical changes will be: > 1) Addressing open issues 1 - 8. In previous e-mails, > I have described these issues. > 2) Adding the idea that a peer = "peer + (optional) SIP entity". > This was already mentioned in the BOF in San Diego. > 3) Adding the third architecture choice that a client might > connect to multiple peers. Eric Rescorla suggested this in an e- > mail > message sent to the list shortly before the San Diego meeting. > > > > > > Sincerely, > > Ed Pimentel > AgileCO > Founder > > Mail: edpimentl[at]gmail.com > sip: sip:2150112@truphone.com > IM: edpimentl [AOL | Jabber | Yahoo | MSN ] > Voip: edpimentl [SKype | GoogleTalk ] > > Mobile Content Marketing/Management/Digital Delivery > http://mobilecentral.ws > > Mobile ( Context, Ambient, Location ) based Social Network > http://TagR.mobi(apha0 > > Mobile Payment - P2P Payment > http://agilepay.ws > > Sponsor of P2PSIP open source [viasip_ng] project > Creating a standards base SKYPE- (open} infrastructure > https://sourceforge.net/projects/viasip/ > Mailing List viasip_ng@freelists.org --Apple-Mail-7-412447826 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 If you mean the latest comments = on the draft,
they have been posted by various people to the mailing = list.
I plan to try to address all comments posted by = people
since the last version (-03) was posted.

If you mean, where is the = latest version of the draft itself,
the latest version is = still the -03 version of last October.
I am working on some = other documents this week
(which are due by the earlier -00 = deadline), and
plan to spend all next week working on the -04 = version.

- = Philip

On 20-Feb-07, at 11:47 , EdPimentl = wrote:

Hello Philip,

Where are the latest comments = available?
-E

On 2/14/07, Philip Matthews <philip_matthews@magma.ca = > wrote:
Just thought I would let folks know what to = expect
in the next version of the Concepts draft.=A0=A0I am working =
away on the respin as time permits, and I fully plan to have = it
out by the deadline, but I don't think it will appear = much
before the deadline because of other things I have to
work on = (including other drafts).

The major technical changes will = be:
1) Addressing open issues 1 - 8.=A0=A0In previous = e-mails,
=A0=A0=A0=A0I have described these issues.
2) Adding the = idea that a peer =3D "peer + (optional) SIP entity".
=A0=A0=A0=A0This = was already mentioned in the BOF in San Diego.
3) Adding the third = architecture choice that a client might
=A0=A0=A0=A0connect to = multiple peers. Eric Rescorla suggested this in an e-mail
=A0=A0=A0=A0m= essage sent to the list shortly before the San Diego meeting. =





Sincerely,

Ed = Pimentel
AgileCO
Founder

Mail:=A0=A0 = edpimentl[at]gmail.com
sip:=A0=A0=A0=A0sip:2150112@truphone.com =
IM:=A0=A0=A0=A0 edpimentl [AOL | Jabber | Yahoo | MSN = ]
Voip:=A0=A0 edpimentl [SKype | GoogleTalk ]

Mobile Content = Marketing/Management/Digital Delivery
http://mobilecentral.ws =

Mobile ( Context, Ambient, Location ) based Social Network
http://TagR.mobi(apha0

Mobile = Payment - P2P Payment
http://agilepay.ws

Sponsor of = P2PSIP=A0=A0open source [viasip_ng] project
Creating a standards base = SKYPE- (open} infrastructure
https://sourceforge.net/= projects/viasip/
Mailing List viasip_ng@freelists.org

= --Apple-Mail-7-412447826-- --===============2046546453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2046546453==-- From p2psip-bounces@ietf.org Tue Feb 20 12:42:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZ05-0006pj-Kj; Tue, 20 Feb 2007 12:42:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZ04-0006pW-9n for p2psip@ietf.org; Tue, 20 Feb 2007 12:42:00 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJZ03-0004Lv-1H for p2psip@ietf.org; Tue, 20 Feb 2007 12:42:00 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDR003VAVTY1Z@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Feb 2007 09:41:58 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JDR007ORVTXQU@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Feb 2007 09:41:58 -0800 (PST) Date: Tue, 20 Feb 2007 11:41:47 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Concepts draft respin To: p2psip@ietf.org Message-id: <01e901c75516$6546aac0$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> <002e01c75509$0caed700$ad600240@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Philip, > I think you have swapped issues 1 and 4 in your message. Sorry if I confused you - thanks for the work you're doing. > Issue 1 was "Do we need a way to discover which peers offer which > services?". > Issue 4 was "Do clients offer services?" > > Brian's posting was on issue #4. > As I stated in > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ > 001983.html > my proposal is to basically punt on this issue for now: > > Open Issue #4: Can clients offer services? Or are services only > offered by peers? > > Summary of Mailing List Discussion: > > Views were mixed. Some supported this proposal, while others did not. > > Enrico suggested that we simply defer this decision by saying that > > services are offered by peer or by peers and clients. > > Proposal: Defer the question and adopt Enrico's proposed wording > for now. > I am hoping that this will satisfy everyone. This question would still appear in the next version of the draft? If so, this is fine. > Regarding issue #1. > I see your point about URIs for non-SIP-based services, but I think we > may > be able to finesse this. We may be able to use a SIP URI to describe the > service, > and return one or more SIP URIs that describe the peers that offer the > service, > even if the service is not SIP-based. > Or we may choose an entirely different way of describing services and the > peers that offer them, since some people have suggested that URIs are not > the right way to describe services. > I will try to capture this debate in some way in the document. Thanks! > And, BTW, I don't expect to get to the serious writing until next Monday. I understand completely. And thanks for holding the pen on this. Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 20 13:59:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaDE-0006vt-54; Tue, 20 Feb 2007 13:59:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaDC-0006vj-PO for p2psip@ietf.org; Tue, 20 Feb 2007 13:59:38 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJaDB-00045S-47 for p2psip@ietf.org; Tue, 20 Feb 2007 13:59:38 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 20 Feb 2007 10:59:36 -0800 X-IronPort-AV: i="4.14,197,1170662400"; d="scan'208"; a="361848580:sNHT89733796" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1KIxaXc031103 for ; Tue, 20 Feb 2007 10:59:36 -0800 Received: from [128.107.139.50] (dhcp-128-107-139-50.cisco.com [128.107.139.50]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1KIxaDk002543 for ; Tue, 20 Feb 2007 10:59:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <01EA40C6-37A8-4B63-B84E-71581A38FA31@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: p2psip@ietf.org From: Cullen Jennings Date: Tue, 20 Feb 2007 10:59:30 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8053; t=1171997976; x=1172861976; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Final=20Charter=20Text |Sender:=20; bh=rb/6d/hfNu2zAf+dHszyzjBfapNUwwzGU+UPaRGNJRE=; b=xrf7ROhOF4Qx8fcfrZ9nE0IonqYEE6OsM03v4iAQyTgZJVk2ssYm0cNP4KC5gRbWqwFGkK7Q GBQYj4n6Cxsr10yWw2wmJDv9uFU68dgAHu1Wt/W/hq4I9w05S3x1KDTN; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [P2PSIP] Final Charter Text X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I collected up the remaining tweeks and have submitted the following as the final charter text. Thanks to all, Cullen Peer-to-Peer Session Initiation Protocol (P2PSIP) Chairs: David A. Bryan Brian Rosen RAI Area Director(s): Cullen Jennings Jon Peterson RAI Area Advisor: Cullen Jennings Mailing Lists: General Discussion: p2psip@ietf.org Subscribe at: https://www1.ietf.org/mailman/listinfo/p2psip Archive at: http://www1.ietf.org/mail-archive/web/p2psip/current 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, rather than centralized servers as in SIP as currently deployed. A number of cases where such an architecture is desirable have been documented. The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality. Session management, messaging, and presence functions are performed using conventional 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 servers. 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. Optionally, 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 P2PSIP Client Protocol is a syntactic subset of the P2PSIP Peer Protocol, and whether the P2PSIP Client Protocol builds on the SIP protocol. 4. A usage document. This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a P2PSIP peer or client, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users of these P2PSIP peers or clients, without relying on centralized servers. Additionally, the document will explain how P2PSIP and conventional SIP entities can interoperate. The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. 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 presented to the BEHAVE or MMUSIC working groups. The working group will assume 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 WG will avoid making protocol design decisions that would preclude the creation of anonymous communications systems using techniques such as onion routing to conceal the IP addresses of P2PSIP peers. P2P networks pose unique security and privacy problems because an adversarial relationship may exist between nodes. Attackers can mount both integrity attacks on the stored data and denial of service attacks on the system as a whole. The WG will not attempt a solution to these issues for P2P networks in general. In order to simplify this problem, the WG will assume that all participants in the system are issued unique identities and credentials through some non-standardized mechanism such as a centralized server and that the data stored in the network will be authenticated by the storing entity, in order to address the integrity issue and to some extent alleviate the DoS issue. Because signaling dialogs may be routed through intermediate P2PSIP peers which may be untrusted by the originating SIP UA, the WG will address the issue of establishing authenticated signaling dialogs through such untrusted relays. P2P systems also have privacy issues because the nodes that store data objects and route requests are unrelated to the clients which want to communicate. In the design of the P2PSIP protocol, the WG will assess these privacy issues and determine to what extent they need to be alleviated. The protocol document will contain a complete description of the privacy properties of P2PSIP. 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. Using URIs need not imply using the DNS or having a record in the DNS for the URI. 4. Multicast and dynamic DNS based approaches as the core lookup mechanism for locating users and resources. Approaches based on these technologies may be reasonable ways to solve similar problems but that is not the focus of this WG. These techniques may be in-scope for locating bootstrap peers/servers or for interoperation with conventional SIP. Goals and Milestones: Jul 2007 WGLC of P2PSIP overview document Sep 2007 Submit P2PSIP overview document to the IESG (Informational) Jan 2008 WGLC of P2PSIP Peer Protocol document Mar 2008 Submit P2PSIP Peer Protocol document to the IESG (PS) Jul 2008 WGLC of P2PSIP Client Protocol document Aug 2008 Submit P2PSIP Client Protocol document to the IESG (PS) Apr 2009 WGLC of P2PSIP usage document May 2009 Submit P2PSIP usage document to the IESG (BCP) _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 20 14:05:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaJF-0003AG-29; Tue, 20 Feb 2007 14:05:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaJE-00036g-AU for p2psip@ietf.org; Tue, 20 Feb 2007 14:05:52 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJaJA-0005DO-WA for p2psip@ietf.org; Tue, 20 Feb 2007 14:05:52 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2007 11:05:41 -0800 X-IronPort-AV: i="4.14,197,1170662400"; d="txt'?scan'208"; a="391290092:sNHT209559866" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1KJ5eqs029760 for ; Tue, 20 Feb 2007 11:05:40 -0800 Received: from [128.107.139.50] (dhcp-128-107-139-50.cisco.com [128.107.139.50]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1KJ5dDk007615 for ; Tue, 20 Feb 2007 11:05:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <01EA40C6-37A8-4B63-B84E-71581A38FA31@cisco.com> References: <01EA40C6-37A8-4B63-B84E-71581A38FA31@cisco.com> Content-Type: multipart/mixed; boundary=Apple-Mail-4-417604997 Message-Id: <146E8E65-F5FD-4F84-AF84-F99FE8654FAC@cisco.com> From: Cullen Jennings Date: Tue, 20 Feb 2007 11:05:33 -0800 To: p2psip@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8645; t=1171998340; x=1172862340; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Final=20Charter=20Text |Sender:=20; bh=9Vb536L2r3LN3MW0XfdziuWw2Hkzn2dvorjgxJRej6s=; b=fSprJUHkGGoUfyMYddwPVM8rk8NfN7AZSj42t8D2f1nsqcx/6M8r3mfV6AWnZZxubOZBO+yn 4ReaPnqYXIglY6/AwLgcHe35aJTtb1t3YFGIRdhSvnlRFAsJJkLtyrfH; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Subject: [P2PSIP] Re: Final Charter Text X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org --Apple-Mail-4-417604997 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Uh, I sent the wrong version in my last email - the correct version is attached. The folks doing the web page did get the right one - just the mailing list got the wrong one :-) --Apple-Mail-4-417604997 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name=P2PSIP-Charter-070220.txt Content-Disposition: attachment; filename=P2PSIP-Charter-070220.txt Peer-to-Peer Session Initiation Protocol (P2PSIP) Chairs: David A. Bryan Brian Rosen RAI Area Director(s): Cullen Jennings Jon Peterson RAI Area Advisor: Cullen Jennings Mailing Lists: General Discussion: p2psip@ietf.org Subscribe at: https://www1.ietf.org/mailman/listinfo/p2psip Archive at: http://www1.ietf.org/mail-archive/web/p2psip/current 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, rather than centralized servers as in SIP as currently deployed. A number of cases where such an architecture is desirable have been documented. The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality. Session management, messaging, and presence functions are performed using conventional 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 servers. 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. Optionally, 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 P2PSIP Client Protocol is a syntactic subset of the P2PSIP Peer Protocol, and whether the P2PSIP Client Protocol builds on the SIP protocol. 4. A usage document. This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a P2PSIP peer or client, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users of these P2PSIP peers or clients, without relying on centralized servers. Additionally, the document will explain how P2PSIP and conventional SIP entities can interoperate. The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. 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 presented to the BEHAVE or MMUSIC working groups. The working group will assume 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 WG will avoid making protocol design decisions that would preclude the creation of anonymous communications systems using techniques such as onion routing to conceal the IP addresses of P2PSIP peers. P2P networks pose unique security and privacy problems because an adversarial relationship may exist between nodes. Attackers can mount both integrity attacks on the stored data and denial of service attacks on the system as a whole. The WG will not attempt a solution to these issues for P2P networks in general. In order to simplify this problem, the WG will assume that all participants in the system are issued unique identities and credentials through some mechanism not in the scope of this working group, such as a centralized server, and that the data stored in the network will be authenticated by the storing entity in order to address the integrity issue and to some extent alleviate the DoS issue. Because signaling dialogs may be routed through intermediate P2PSIP peers which may be untrusted by the originating SIP UA, the WG will address the issue of establishing authenticated signaling dialogs through such untrusted relays. P2P systems also have privacy issues because the nodes that store data objects and route requests are unrelated to the clients which want to communicate. In the design of the P2PSIP protocol, the WG will assess these privacy issues and determine to what extent they need to be alleviated. The protocol document will contain a complete description of the privacy properties of P2PSIP. 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. Using URIs need not imply using the DNS or having a record in the DNS for the URI. 4. Multicast and dynamic DNS based approaches as the core lookup mechanism for locating users and resources. Approaches based on these technologies may be reasonable ways to solve similar problems but that is not the focus of this WG. These techniques may be in-scope for locating bootstrap peers/servers or for interoperation with conventional SIP. Goals and Milestones: Jul 2007 WGLC of P2PSIP overview document Sep 2007 Submit P2PSIP overview document to the IESG (Informational) Jan 2008 WGLC of P2PSIP Peer Protocol document Mar 2008 Submit P2PSIP Peer Protocol document to the IESG (PS) Jul 2008 WGLC of P2PSIP Client Protocol document Aug 2008 Submit P2PSIP Client Protocol document to the IESG (PS) Apr 2009 WGLC of P2PSIP usage document May 2009 Submit P2PSIP usage document to the IESG (BCP) --Apple-Mail-4-417604997 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-4-417604997 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Apple-Mail-4-417604997-- From p2psip-bounces@ietf.org Tue Feb 20 17:43:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdhp-0003Ap-JQ; Tue, 20 Feb 2007 17:43:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdho-0003Aj-H4 for p2psip@ietf.org; Tue, 20 Feb 2007 17:43:28 -0500 Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJdhn-0002s4-4w for p2psip@ietf.org; Tue, 20 Feb 2007 17:43:28 -0500 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1KMhP4a029674; Tue, 20 Feb 2007 17:43:25 -0500 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l1KMhN7N023841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Feb 2007 17:43:25 -0500 In-Reply-To: <01e901c75516$6546aac0$ad600240@china.huawei.com> References: <9A11D966-AD17-441A-A73A-61D8129A7169@magma.ca> <002e01c75509$0caed700$ad600240@china.huawei.com> <01e901c75516$6546aac0$ad600240@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CC0AB16-CAEC-4216-B2F0-5914182CC072@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Concepts draft respin Date: Tue, 20 Feb 2007 17:44:23 -0500 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 20-Feb-07, at 12:41 , Spencer Dawkins wrote: > Hi, Philip, > >> I think you have swapped issues 1 and 4 in your message. > > Sorry if I confused you - thanks for the work you're doing. > >> Issue 1 was "Do we need a way to discover which peers offer which >> services?". >> Issue 4 was "Do clients offer services?" >> >> Brian's posting was on issue #4. >> As I stated in >> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ >> 001983.html >> my proposal is to basically punt on this issue for now: >> > Open Issue #4: Can clients offer services? Or are services only >> offered by peers? >> > Summary of Mailing List Discussion: >> > Views were mixed. Some supported this proposal, while others did >> not. >> > Enrico suggested that we simply defer this decision by saying that >> > services are offered by peer or by peers and clients. >> > Proposal: Defer the question and adopt Enrico's proposed wording >> for now. >> I am hoping that this will satisfy everyone. > > This question would still appear in the next version of the draft? > If so, this is fine. I will probably mention this issue at one spot in the document, and then use the wording above "peers or peers and clients" or something similar elsewhere when discussing services. > >> Regarding issue #1. >> I see your point about URIs for non-SIP-based services, but I >> think we may >> be able to finesse this. We may be able to use a SIP URI to >> describe the service, >> and return one or more SIP URIs that describe the peers that >> offer the service, >> even if the service is not SIP-based. >> Or we may choose an entirely different way of describing services >> and the >> peers that offer them, since some people have suggested that URIs >> are not >> the right way to describe services. >> I will try to capture this debate in some way in the document. > > Thanks! > >> And, BTW, I don't expect to get to the serious writing until next >> Monday. > > I understand completely. And thanks for holding the pen on this. > > Spencer > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 21 02:43:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJm8G-00088N-1P; Wed, 21 Feb 2007 02:43:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJm8E-00088G-T7 for P2PSIP@ietf.org; Wed, 21 Feb 2007 02:43:18 -0500 Received: from mo-p00-ob.rzone.de ([81.169.146.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJm8A-0006YV-Fk for P2PSIP@ietf.org; Wed, 21 Feb 2007 02:43:18 -0500 Received: from FWeber ([194.94.81.61] [194.94.81.61]) by post.webmailer.de (mrclete mo25) (RZmta 4.7) with SMTP id D0493dj1L5gWTJ for ; Wed, 21 Feb 2007 08:43:12 +0100 (MET) Message-ID: <003801c7558b$f01e2130$be00a8c0@FWeber> From: "Frank Weber" To: Date: Wed, 21 Feb 2007 08:43:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-RZG-AUTH: lUESckh7NXIBRwIBeoLQAvOp/S1XEYczYRR87FtgJoxFajiKGwEP3xfUcgXTLFQN3o8I X-RZG-CLASS-ID: mo00 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [P2PSIP] P2PSIP WG web page URL? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi to everybody, does anyone know the prospective URL for the P2PSIP WG web page for sure? I need this as a source. Best regards Frank --------------------------------------------------- Dipl.-Ing. (FH) Frank Weber Fachhochschule Frankfurt am Main - University of Applied Sciences FB 2 - Computer Science and Engineering Research Group for Telecommunication Networks Kleiststr. 3 60318 Frankfurt am Main GERMANY Tel.: +49 (0) 69 1533 3610 Fax: +49 (0) 69 1539 5224 961 mailto:weber@e-technik.org sip:8709905@sipgate.de http://www.fh-frankfurt.de/~weberfra _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 21 15:56:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJyVP-0005Gy-Gc; Wed, 21 Feb 2007 15:56:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJyQ4-000660-Rj; Wed, 21 Feb 2007 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJyQ4-0004IE-ED; Wed, 21 Feb 2007 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 55A1E1762D; Wed, 21 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJyPa-0007jb-3q; Wed, 21 Feb 2007 15:50:02 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Wed, 21 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.3 (--) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 X-Mailman-Approved-At: Wed, 21 Feb 2007 15:56:01 -0500 Cc: p2psip@ietf.org Subject: [P2PSIP] WG Action: Peer-to-Peer Session Initiation Protocol (p2psip) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Peer-to-Peer Session Initiation Protocol (p2psip) =================================================== Current Status: 2007-2-21 Chairs: David A. Bryan Brian Rosen RAI Area Director(s): Cullen Jennings Jon Peterson RAI Area Advisor: Cullen Jennings Mailing Lists: General Discussion: p2psip@ietf.org Subscribe at: https://www1.ietf.org/mailman/listinfo/p2psip Archive at: http://www1.ietf.org/mail-archive/web/p2psip/current 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, rather than centralized servers as in SIP as currently deployed. A number of cases where such an architecture is desirable have been documented. The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality. Session management, messaging, and presence functions are performed using conventional 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 servers. 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. Optionally, 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 P2PSIP Client Protocol is a syntactic subset of the P2PSIP Peer Protocol, and whether the P2PSIP Client Protocol builds on the SIP protocol. 4. A usage document. This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a P2PSIP peer or client, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users of these P2PSIP peers or clients, without relying on centralized servers. Additionally, the document will explain how P2PSIP and conventional SIP entities can interoperate. The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. 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 presented to the BEHAVE or MMUSIC working groups. The working group will assume 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 WG will avoid making protocol design decisions that would preclude the creation of anonymous communications systems using techniques such as onion routing to conceal the IP addresses of P2PSIP peers. P2P networks pose unique security and privacy problems because an adversarial relationship may exist between nodes. Attackers can mount both integrity attacks on the stored data and denial of service attacks on the system as a whole. The WG will not attempt a solution to these issues for P2P networks in general. In order to simplify this problem, the WG will assume that all participants in the system are issued unique identities and credentials through some mechanism not in the scope of this working group, such as a centralized server, and that the data stored in the network will be authenticated by the storing entity in order to address the integrity issue and to some extent alleviate the DoS issue. Because signaling dialogs may be routed through intermediate P2PSIP peers which may be untrusted by the originating SIP UA, the WG will address the issue of establishing authenticated signaling dialogs through such untrusted relays. P2P systems also have privacy issues because the nodes that store data objects and route requests are unrelated to the clients which want to communicate. In the design of the P2PSIP protocol, the WG will assess these privacy issues and determine to what extent they need to be alleviated. The protocol document will contain a complete description of the privacy properties of P2PSIP. 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. Using URIs need not imply using the DNS or having a record in the DNS for the URI. 4. Multicast and dynamic DNS based approaches as the core lookup mechanism for locating users and resources. Approaches based on these technologies may be reasonable ways to solve similar problems but that is not the focus of this WG. These techniques may be in-scope for locating bootstrap peers/servers or for interoperation with conventional SIP. Goals and Milestones: Jul 2007 WGLC of P2PSIP overview document Sep 2007 Submit P2PSIP overview document to the IESG (Informational) Jan 2008 WGLC of P2PSIP Peer Protocol document Mar 2008 Submit P2PSIP Peer Protocol document to the IESG (PS) Jul 2008 WGLC of P2PSIP Client Protocol document Aug 2008 Submit P2PSIP Client Protocol document to the IESG (PS) Apr 2009 WGLC of P2PSIP usage document May 2009 Submit P2PSIP usage document to the IESG (BCP) _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 21 17:34:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK02g-0003a0-T6; Wed, 21 Feb 2007 17:34:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK01y-0003FL-IR for p2psip@ietf.org; Wed, 21 Feb 2007 17:33:46 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJzxg-0006SW-1v for p2psip@ietf.org; Wed, 21 Feb 2007 17:29:21 -0500 Received: from [64.101.172.227] ([64.101.172.227]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l1LLYwfV023392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Feb 2007 15:34:58 -0600 In-Reply-To: <008701c7550a$5855cb40$ad600240@china.huawei.com> References: <4553C513-0067-44FB-962A-1B864BCE2061@magma.ca> <008701c7550a$5855cb40$ad600240@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26806B3B-90B4-4CB2-B9D0-238AC6067100@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Re: [p2p-sip] Concept Draft Open Issue #7: Add concept of "Admittingpeer"? Date: Wed, 21 Feb 2007 16:29:10 -0600 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Spencer on this one, making for a transitive agreement with Philip's proposals. -- Dean On Feb 20, 2007, at 10:15 AM, Spencer Dawkins wrote: > I didn't see any followup onlist for this open issue, and wanted to > say that I agree with Philip's proposal. > > Philip said: >> >> This also leads to a possible terminology changes. >> First of all, the term "joining peer" as the name for the peer >> that is joining the overlay. >> Second, replacing the current term "peer insertion" with >> "peer admission", to show that the Overlay may reject the >> joining peer, if the joining peer does not have the correct >> credentials to join. >> >> Proposal: Add the above concepts to the Concepts draft, >> along with the proposed terminology changes. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 21 18:45:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK196-00035U-5q; Wed, 21 Feb 2007 18:45:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK195-0002yq-2q for P2PSIP@ietf.org; Wed, 21 Feb 2007 18:45:11 -0500 Received: from mx5-4.spamtrap.magma.ca ([209.217.78.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK190-0002ue-NM for P2PSIP@ietf.org; Wed, 21 Feb 2007 18:45:11 -0500 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx5-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1LNixJe005095; Wed, 21 Feb 2007 18:44:59 -0500 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l1LNiw8Z019075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Feb 2007 18:44:59 -0500 In-Reply-To: <003801c7558b$f01e2130$be00a8c0@FWeber> References: <003801c7558b$f01e2130$be00a8c0@FWeber> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] P2PSIP WG web page URL? Date: Wed, 21 Feb 2007 18:46:01 -0500 To: Frank Weber X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: P2PSIP@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Do you mean http://www.ietf.org/html.charters/p2psip-charter.html which just went up today? - Philip On 21-Feb-07, at 02:43 , Frank Weber wrote: > Hi to everybody, > > does anyone know the prospective URL for the P2PSIP WG web page for > sure? I need this as a source. > > Best regards > > Frank > > --------------------------------------------------- > Dipl.-Ing. (FH) Frank Weber > > Fachhochschule Frankfurt am Main > - University of Applied Sciences > FB 2 - Computer Science and Engineering > Research Group for Telecommunication Networks > Kleiststr. 3 > 60318 Frankfurt am Main > GERMANY > Tel.: +49 (0) 69 1533 3610 > Fax: +49 (0) 69 1539 5224 961 > mailto:weber@e-technik.org > sip:8709905@sipgate.de > http://www.fh-frankfurt.de/~weberfra > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Feb 24 12:16:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL0Vk-0007qy-HY; Sat, 24 Feb 2007 12:16:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL0Vi-0007qq-4g for p2psip@ietf.org; Sat, 24 Feb 2007 12:16:38 -0500 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HL0Vc-000380-SM for p2psip@ietf.org; Sat, 24 Feb 2007 12:16:38 -0500 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l1OHGTPB032747; Sat, 24 Feb 2007 12:16:29 -0500 Received: from [10.0.1.2] ([24.139.16.154]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id l1OHGRuj031360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 24 Feb 2007 12:16:28 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <93A82FAF-A28E-419B-AB9A-BF05BEB8D707@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sat, 24 Feb 2007 12:16:25 -0500 To: p2psip@ietf.org X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [P2PSIP] New draft on Bootstrap Mechanisms X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Cooper, Alan Johnston, and I have written a draft that describes how to a peer that wishes to join a P2PSIP overlay can locate a peer in the overlay ("the bootstrap peer") and then set up the first initial connection to the overlay. The current version of the draft describes two mechanisms. One mechanism uses multicast to locate a bootstrap peer, while the other uses a bootstrap server to locate a bootstrap peer. These two mechanisms are described at a high-level in the Concepts draft. What this new draft does is provide detailed descriptions of the mechanisms. To provide a detailed description, we had to make a few assumptions. The most important of these assumptions is that SIP is the protocol for signaling Peer Protocol connections. [Note that we are NOT saying that the Peer Protocol is SIP; in fact, we were careful to assume as little as possible about the nature of the Peer Protocol.] The main reason we picked SIP is because it is a sophisticated signaling protocol and already has security and NAT traversal mechanisms defined. The current version of the draft does not define any new SIP mechanisms, but manages to do everything using existing SIP mechanisms, albeit in new and interesting ways. In fact, this was the interesting part in working on the draft . We new at the start more or less what we wanted to do, and the challenge was to figure out how to do this without having to extend SIP. [I should add that some SIP and SDP extensions WILL be required before everything is finalized, to define for example, how to specify the Peer Protocol in SDP, but our draft currently leaves these to be defined elsewhere.] The draft has a file name of draft-matthews-p2psip-bootstrap-mechanisms-00 Until the draft shows up in the Internet-Draft archives, you can pick up a copy on my website: www.magma.ca/~philip_matthews I have also placed an HTML version of the draft there. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Feb 25 20:33:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLUkT-0007UN-BL; Sun, 25 Feb 2007 20:33:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLUkS-0007UB-5F for p2psip@ietf.org; Sun, 25 Feb 2007 20:33:52 -0500 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLUkL-00075m-6U for p2psip@ietf.org; Sun, 25 Feb 2007 20:33:51 -0500 Received: by an-out-0708.google.com with SMTP id d30so776695and for ; Sun, 25 Feb 2007 17:33:44 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=go2c+uNC25FLPsOFN/srgxUViyFO93EbpCohjil3+HG34AO1y+ad6UEbI7JqhLbjHPZVq3MI0SQANHm185RJn6tybvE2JtDjC21PYQdY+PVQsxj42nvg8NcgJ+csdQSdbrICE7Ry2T4TfEDVijEBvcfWlSKHzbXp1t4WflRXUso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=KFN+GFZm0oPLcGn3fgf0JIdg+c/o+c0wvZ4SxTC2iwR3PFtOwr/oD+/DGsscGT4su+Lm4qqmIAFR1D1r/lgx67QpRQ6AeLlj2izWlpNjpOeyZjH6dnEwCruYUMl+1FhgxLGHtRCKwyB/ZoG5GIkec9rUZbiTnrvbe9mGVOUkM0I= Received: by 10.114.126.1 with SMTP id y1mr1142557wac.1172453620097; Sun, 25 Feb 2007 17:33:40 -0800 (PST) Received: by 10.115.88.9 with HTTP; Sun, 25 Feb 2007 17:33:40 -0800 (PST) Message-ID: <20d2bdfb0702251733t1e66de33ldb74d0c3adf763dc@mail.gmail.com> Date: Sun, 25 Feb 2007 20:33:40 -0500 From: "Bruce Lowekamp" To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 7a27521aaf179d28 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [P2PSIP] new dSIP drafts evolving from draft-bryan-sipping-p2p-03 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We have just submitted a set of drafts that have evolved from and extended what was draft-bryan-sipping-p2p-03. We have adopted the name distributed SIP (dSIP) for the protocol described in these drafts. Until they are officially posted, they are available online at http://www.p2psip.org/ietf.php The drafts are: David A. Bryan, Bruce B. Lowekamp, and Cullen Jennings, dSIP: A P2P Approach to SIP Registration and Resource Location, draft-bryan-p2psip-dsip-00 Marcia Zangrilli and David A. Bryan, A Chord-based DHT for Resource Lookup in P2PSIP, draft-zangrilli-p2psip-dsip-dhtchord-00 Eric Cooper, Philip Matthews, David A. Bryan, and Bruce B. Lowekamp, NAT Traversal for dSIP, draft-matthews-p2psip-dsip-nat-traversal-00 Bruce B. Lowekamp and James W. Deverick, Authenticated Identity Extensions to dSIP, draft-lowekamp-p2psip-dsip-security-00 Marcia Zangrilli and David A. Bryan: A Bamboo-based DHT for Resource Lookup in P2PSIP, draft-zangrilli-p2psip-dsip-dhtbamboo-00 We look forward to your comments and hope to see everyone in Prague. David Bryan, Eric Cooper, James Deverick, Cullen Jennings, Bruce Lowekamp, Philip Matthews, and Marcia Zangrilli _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Feb 26 13:23:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkVE-0003Op-KU; Mon, 26 Feb 2007 13:23:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkVD-0003Ok-My for p2psip@ietf.org; Mon, 26 Feb 2007 13:23:11 -0500 Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLkVC-0005Ga-Ax for p2psip@ietf.org; Mon, 26 Feb 2007 13:23:11 -0500 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1QIMx7c017912; Mon, 26 Feb 2007 13:22:59 -0500 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l1QIMuU6010675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Feb 2007 13:22:57 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 26 Feb 2007 13:22:58 -0500 To: p2psip@ietf.org X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [P2PSIP] Concept draft: Open issues #5 - 8 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Folks: Back in late January I posted four more open issues for the Concepts draft. There was some discussion on these, and I am going to summarize here what I think was agreed to as a result of these discussions. I plan to make these changes to the draft in the next couple of days. - Philip Open issue #5: Users vs. Resources vs. Services. https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html ======================================= I propose to go with the following description of these. This is my original proposal above except for the addition of a change suggested by Richard Barnes. Users are humans. A user may be represented in the P2P Overlay by multiple UAs, which represent the various different ways that the user may be contacted (e.g., desk phone, mobile). Some of these may answer even if the user is not available (e.g., voicemail server). A service represents something that a peer can do on behalf of another peer. Multiple peers may offer the same service. Within a service type (e.g., "STUN server"), there may be differentiation between the peers on the exact sub-type of the service provided (e.g., "STUN server" vs. "STUN server with relay service"). However, once the sub-type is selected, the service is identical between peers, so which one to contact can be determined by things such as net-path efficiency. Information about a UA, user, or service may be stored in the distributed database. The information is stored in a "record", which has an associated "key" which is used for lookup. It may be that a P2PSIP Overlay will store other information in the distributed database. Generically, we use the term "resource" for the information that can be stored in the distributed database. Open issue #6: Data Model vs Service Model https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html ========================================================= I propose to add the concept of a Data Model vs a Service Model, as described in http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 and http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-01.txt Dan Romascanu requested that we come up with different terms, and I will try to do that. (Feel free to make suggestions!) Open issue #7: Admitting Peer https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002000.html ========================================================= I propose to add the terms "Joining Peer" and "Admitting Peer" and change "Peer Insertion" to "Peer Admission". Open issue #8: Expressing "Client protocol = SIP?" https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002013.html ========================================================= I propose to rephase this question as "Do clients exist?". _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Feb 26 13:39:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkkY-0006SO-NV; Mon, 26 Feb 2007 13:39:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkkX-0006S7-CI for p2psip@ietf.org; Mon, 26 Feb 2007 13:39:01 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLkkK-0007y5-J4 for p2psip@ietf.org; Mon, 26 Feb 2007 13:39:01 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE300MFC2GNF4@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Feb 2007 10:38:47 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JE300LZY2GIGJ@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Feb 2007 10:38:47 -0800 (PST) Date: Mon, 26 Feb 2007 12:38:24 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Concept draft: Open issues #5 - 8 To: p2psip@ietf.org Message-id: <024901c759d5$501fb5b0$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Philip, Thanks for the heads-up on these proposed changes. Comments follow. Spencer > Folks: > > Back in late January I posted four more open issues for the Concepts > draft. > There was some discussion on these, and I am going to summarize here > what I think was agreed to as a result of these discussions. > > I plan to make these changes to the draft in the next couple of days. > > - Philip > > > Open issue #5: Users vs. Resources vs. Services. > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html > ======================================= > I propose to go with the following description of these. This is my > original proposal above > except for the addition of a change suggested by Richard Barnes. > > Users are humans. A user may be represented in the P2P Overlay by > multiple UAs, which represent the various different ways that the > user may be contacted (e.g., desk phone, mobile). Some of these may > answer even if the user is not available (e.g., voicemail server). > > A service represents something that a peer can do on behalf of > another peer. Multiple peers may offer the same service. Within a > service type (e.g., "STUN server"), there may be differentiation > between the peers on the exact sub-type of the service provided > (e.g., "STUN server" vs. "STUN server with relay service"). However, > once the sub-type is selected, the service is identical between > peers, so which one to contact can be determined by things such as > net-path efficiency. After reading current shake-and-bake discussions about "service ID" on the SIPPING mailing list, if we can avoid using the word "service" in P2PSIP, that would be lovely. At the very least, the question of addressing should be mentioned - some people have assumed there's a SIP URI for services, while others are using service to include non-SIP "services" like STUN. > Information about a UA, user, or service may be stored in the distributed > database. The information is stored in a "record", which has an > associated "key" which is used for lookup. > > It may be that a P2PSIP Overlay will store other information in the > distributed database. Generically, we use the term "resource" for > the information that can be stored in the distributed database. > > > > Open issue #6: Data Model vs Service Model > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html > ========================================================= > I propose to add the concept of a Data Model vs a Service Model, > as described in > http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 > and > http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-01.txt > Dan Romascanu requested that we come up with different terms, > and I will try to do that. (Feel free to make suggestions!) I agree that both of these are overloaded now... > Open issue #7: Admitting Peer > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002000.html > ========================================================= > I propose to add the terms "Joining Peer" and "Admitting Peer" > and change "Peer Insertion" to "Peer Admission". I agree with this proposed change. > Open issue #8: Expressing "Client protocol = SIP?" > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002013.html > ========================================================= > I propose to rephase this question as "Do clients exist?". I agree with this proposed change, but isn't there a parallel question like "Peer protocol = SIP?"? _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Feb 26 13:56:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLl1a-000653-69; Mon, 26 Feb 2007 13:56:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLl1Z-00064t-4p for p2psip@ietf.org; Mon, 26 Feb 2007 13:56:37 -0500 Received: from mx1-3.spamtrap.magma.ca ([209.217.78.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLl1N-0003u1-Ar for p2psip@ietf.org; Mon, 26 Feb 2007 13:56:36 -0500 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx1-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1QIuNDa019082; Mon, 26 Feb 2007 13:56:23 -0500 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l1QIuGtZ028745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Feb 2007 13:56:22 -0500 In-Reply-To: <024901c759d5$501fb5b0$6501a8c0@china.huawei.com> References: <024901c759d5$501fb5b0$6501a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Concept draft: Open issues #5 - 8 Date: Mon, 26 Feb 2007 13:56:17 -0500 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org See inline. - Philip On 26-Feb-07, at 13:38 , Spencer Dawkins wrote: > Hi, Philip, > > Thanks for the heads-up on these proposed changes. Comments follow. > > Spencer > > >> Folks: >> >> Back in late January I posted four more open issues for the >> Concepts draft. >> There was some discussion on these, and I am going to summarize here >> what I think was agreed to as a result of these discussions. >> >> I plan to make these changes to the draft in the next couple of days. >> >> - Philip >> >> >> Open issue #5: Users vs. Resources vs. Services. >> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ >> 001998.html >> ======================================= >> I propose to go with the following description of these. This is >> my original proposal above >> except for the addition of a change suggested by Richard Barnes. >> >> Users are humans. A user may be represented in the P2P Overlay by >> multiple UAs, which represent the various different ways that the >> user may be contacted (e.g., desk phone, mobile). Some of these may >> answer even if the user is not available (e.g., voicemail server). >> >> A service represents something that a peer can do on behalf of >> another peer. Multiple peers may offer the same service. Within a >> service type (e.g., "STUN server"), there may be differentiation >> between the peers on the exact sub-type of the service provided >> (e.g., "STUN server" vs. "STUN server with relay service"). However, >> once the sub-type is selected, the service is identical between >> peers, so which one to contact can be determined by things such as >> net-path efficiency. > > After reading current shake-and-bake discussions about "service ID" > on the SIPPING mailing list, if we can avoid using the word > "service" in P2PSIP, that would be lovely. At the very least, the > question of addressing should be mentioned - some people have > assumed there's a SIP URI for services, while others are using > service to include non-SIP "services" like STUN. Do you have a proposal for an alternative name for "service"? (You knew that was coming, didn't you? :-) As for the URI question, I will discuss this. > >> Information about a UA, user, or service may be stored in the >> distributed >> database. The information is stored in a "record", which has an >> associated "key" which is used for lookup. >> >> It may be that a P2PSIP Overlay will store other information in the >> distributed database. Generically, we use the term "resource" for >> the information that can be stored in the distributed database. >> >> >> >> Open issue #6: Data Model vs Service Model >> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ >> 001998.html >> ========================================================= >> I propose to add the concept of a Data Model vs a Service Model, >> as described in >> http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 >> and >> http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-01.txt >> Dan Romascanu requested that we come up with different terms, >> and I will try to do that. (Feel free to make suggestions!) > > I agree that both of these are overloaded now... > >> Open issue #7: Admitting Peer >> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ >> 002000.html >> ========================================================= >> I propose to add the terms "Joining Peer" and "Admitting Peer" >> and change "Peer Insertion" to "Peer Admission". > > I agree with this proposed change. > >> Open issue #8: Expressing "Client protocol = SIP?" >> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ >> 002013.html >> ========================================================= >> I propose to rephase this question as "Do clients exist?". > > I agree with this proposed change, but isn't there a parallel > question like "Peer protocol = SIP?"? I think this is already mentioned, but I will make sure it is there in the next version. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Feb 26 14:59:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLm0R-0005aF-OL; Mon, 26 Feb 2007 14:59:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLm0Q-0005Z1-8j for p2psip@ietf.org; Mon, 26 Feb 2007 14:59:30 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLm0O-0004wu-Rq for p2psip@ietf.org; Mon, 26 Feb 2007 14:59:30 -0500 Received: by nf-out-0910.google.com with SMTP id l36so2050883nfa for ; Mon, 26 Feb 2007 11:59:28 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=BqmC6wEiq+OwhcNoLYFZkG6+BlKmjv6dH8RRGDqRkokgARM+jBW3GrzLDyssVXJGLxEXtd3kDSvPxHSZPv9t0YyXVf6Ir/DG0EyfYJmE0xkd/OC+0IjoA5SRzh+Qo7XrbRb7koKKDYbaAafGuo1aHnZFSS2koVunpS8XPR1IP4Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mD655Xjz8UIpi238DrkN9C0HdGr/pFjkyzhnuYGIdcoHVJhGS/jwc009kn/DC2wtYpxVloGIOXxkwXvvhY6QzxjWyVpqcW+4YtZbcL4YXt57od1TY0acltI4kxXFEHpVxyoQHcWmND4wiCJQcVhqZf5l/2FYhXMrBiSX08yjPy0= Received: by 10.82.152.16 with SMTP id z16mr1955565bud.1172519967532; Mon, 26 Feb 2007 11:59:27 -0800 (PST) Received: by 10.82.106.15 with HTTP; Mon, 26 Feb 2007 11:59:27 -0800 (PST) Message-ID: <4d4304a00702261159k1d5b5f6fwb0635b625dac9467@mail.gmail.com> Date: Mon, 26 Feb 2007 14:59:27 -0500 From: "David A. Bryan" To: "Philip Matthews" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 2266a8c254d4ea54 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: p2psip@ietf.org Subject: [P2PSIP] Re: Concept draft: Open issues #5 - 8 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Only question I have is about services that are people specific (wow, I'm digging into odd turf here). What about things like VM? It is a service, but located on a per-user basis. I'm personally fine just treating that as a user-level resource, but wanted to see what others thought. David On 2/26/07, Philip Matthews wrote: > Folks: > > Back in late January I posted four more open issues for the Concepts > draft. > There was some discussion on these, and I am going to summarize here > what I think was agreed to as a result of these discussions. > > I plan to make these changes to the draft in the next couple of days. > > - Philip > > > Open issue #5: Users vs. Resources vs. Services. > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html > ======================================= > I propose to go with the following description of these. This is my > original proposal above > except for the addition of a change suggested by Richard Barnes. > > Users are humans. A user may be represented in the P2P Overlay by > multiple UAs, which represent the various different ways that the > user may be contacted (e.g., desk phone, mobile). Some of these may > answer even if the user is not available (e.g., voicemail server). > > A service represents something that a peer can do on behalf of > another peer. Multiple peers may offer the same service. Within a > service type (e.g., "STUN server"), there may be differentiation > between the peers on the exact sub-type of the service provided > (e.g., "STUN server" vs. "STUN server with relay service"). However, > once the sub-type is selected, the service is identical between > peers, so which one to contact can be determined by things such as > net-path efficiency. > > Information about a UA, user, or service may be stored in the > distributed > database. The information is stored in a "record", which has an > associated "key" which is used for lookup. > > It may be that a P2PSIP Overlay will store other information in the > distributed database. Generically, we use the term "resource" for > the information that can be stored in the distributed database. > > > > Open issue #6: Data Model vs Service Model > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html > ========================================================= > I propose to add the concept of a Data Model vs a Service Model, > as described in > http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 > and > http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-01.txt > Dan Romascanu requested that we come up with different terms, > and I will try to do that. (Feel free to make suggestions!) > > > > Open issue #7: Admitting Peer > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002000.html > ========================================================= > I propose to add the terms "Joining Peer" and "Admitting Peer" > and change "Peer Insertion" to "Peer Admission". > > > > Open issue #8: Expressing "Client protocol = SIP?" > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002013.html > ========================================================= > I propose to rephase this question as "Do clients exist?". > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Feb 26 15:15:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmFk-00011Z-VP; Mon, 26 Feb 2007 15:15:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmFj-00011S-PF for p2psip@ietf.org; Mon, 26 Feb 2007 15:15:19 -0500 Received: from mx1-3.spamtrap.magma.ca ([209.217.78.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmFe-0007zv-5i for p2psip@ietf.org; Mon, 26 Feb 2007 15:15:19 -0500 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx1-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1QKF86q030294; Mon, 26 Feb 2007 15:15:09 -0500 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l1QKEm6q021325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Feb 2007 15:14:49 -0500 In-Reply-To: <4d4304a00702261159k1d5b5f6fwb0635b625dac9467@mail.gmail.com> References: <4d4304a00702261159k1d5b5f6fwb0635b625dac9467@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 26 Feb 2007 15:14:49 -0500 To: "David A. Bryan" X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: p2psip@ietf.org Subject: [P2PSIP] Re: Concept draft: Open issues #5 - 8 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Regarding VoiceMail, here is one way to make it work. A peer that is willing to act as a VoiceMail server registers as a contact for the "VoiceMail" service. When a User wants to enable VoiceMail, her UA does a lookup on the VoiceMail service and gets back a list of peers. The UA picks one of these peers and contacts it and arranges for it to act as a "VoiceMail taker" for the user. The peer then registers with the UA as a contact point for the user, presumably with a q value of .5 or similar. So the "service" is the ability to take voicemail. To register as a VM contact for a user, the peer registers as a UA for the user. - Philip On 26-Feb-07, at 14:59 , David A. Bryan wrote: > Only question I have is about services that are people specific (wow, > I'm digging into odd turf here). What about things like VM? It is a > service, but located on a per-user basis. > > I'm personally fine just treating that as a user-level resource, but > wanted to see what others thought. > > David > > On 2/26/07, Philip Matthews wrote: >> Folks: >> >> Back in late January I posted four more open issues for the Concepts >> draft. >> There was some discussion on these, and I am going to summarize here >> what I think was agreed to as a result of these discussions. >> >> I plan to make these changes to the draft in the next couple of days. >> >> - Philip >> >> >> Open issue #5: Users vs. Resources vs. Services. >> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ >> 001998.html >> ======================================= >> I propose to go with the following description of these. This is my >> original proposal above >> except for the addition of a change suggested by Richard Barnes. >> >> Users are humans. A user may be represented in the P2P Overlay by >> multiple UAs, which represent the various different ways that the >> user may be contacted (e.g., desk phone, mobile). Some of these may >> answer even if the user is not available (e.g., voicemail server). >> >> A service represents something that a peer can do on behalf of >> another peer. Multiple peers may offer the same service. Within a >> service type (e.g., "STUN server"), there may be differentiation >> between the peers on the exact sub-type of the service provided >> (e.g., "STUN server" vs. "STUN server with relay service"). However, >> once the sub-type is selected, the service is identical between >> peers, so which one to contact can be determined by things such as >> net-path efficiency. >> >> Information about a UA, user, or service may be stored in the >> distributed >> database. The information is stored in a "record", which has an >> associated "key" which is used for lookup. >> >> It may be that a P2PSIP Overlay will store other information in the >> distributed database. Generically, we use the term "resource" for >> the information that can be stored in the distributed database. >> >> >> >> Open issue #6: Data Model vs Service Model >> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ >> 001998.html >> ========================================================= >> I propose to add the concept of a Data Model vs a Service Model, >> as described in >> http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 >> and >> http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-01.txt >> Dan Romascanu requested that we come up with different terms, >> and I will try to do that. (Feel free to make suggestions!) >> >> >> >> Open issue #7: Admitting Peer >> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ >> 002000.html >> ========================================================= >> I propose to add the terms "Joining Peer" and "Admitting Peer" >> and change "Peer Insertion" to "Peer Admission". >> >> >> >> Open issue #8: Expressing "Client protocol = SIP?" >> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/ >> 002013.html >> ========================================================= >> I propose to rephase this question as "Do clients exist?". >> >> > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Feb 26 17:14:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLo7I-0002xc-J2; Mon, 26 Feb 2007 17:14:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnp5-0007w4-Ic for p2psip@ietf.org; Mon, 26 Feb 2007 16:55:55 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLnee-00052c-2z for p2psip@ietf.org; Mon, 26 Feb 2007 16:45:10 -0500 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l1QLj3Ul017025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 26 Feb 2007 16:45:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <6EE33BBC-AE79-46D9-8DE6-6A3871EA16DF@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: p2psip@ietf.org From: Henning Schulzrinne Date: Mon, 26 Feb 2007 16:45:13 -0500 X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [P2PSIP] New draft on DNS-SD discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The draft below defines a mechanism to use DNS-SD (aka "Apple Bonjour") for distributing SIP URIs in a LAN. This is FYI only, as the topic is outside the core charter of the WG, but individual feedback is appreciated. Title : SIP URI Service Discovery using DNS-SD Author(s) : J. Lee, H. Schulzrinne Filename : draft-lee-sip-dns-sd-uri-00.txt Pages : 17 Date : 2007-2-26 This document describes the Session Initiation Protocol Uniform Resource Identifier (SIP URI) advertisement for DNS-based Service Discovery (DNS-SD). Using this mechanism, a SIP user agent (UA) can communicate with another UA even when no SIP registrar is available, as in a wireless ad-hoc network for example. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-sip-dns-sd-uri-00.txt _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Feb 26 20:52:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLrVZ-0002uc-8c; Mon, 26 Feb 2007 20:52:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLrTu-0001HU-PJ for p2psip@ietf.org; Mon, 26 Feb 2007 20:50:19 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLrTr-00007o-I6 for p2psip@ietf.org; Mon, 26 Feb 2007 20:50:18 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE30064RMEBZ3@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 27 Feb 2007 09:49:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JE300490MEBAJ@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 27 Feb 2007 09:49:23 +0800 (CST) Received: from j36340 ([10.164.5.114]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JE300LAUME8U7@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 27 Feb 2007 09:49:23 +0800 (CST) Date: Tue, 27 Feb 2007 09:49:20 +0800 From: JiangXingFeng To: p2psip@ietf.org Message-id: <001e01c75a11$7f8bf110$7205a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcdaEX8lEUzsWzQiSjCqQJkLS8obLg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [P2PSIP] New draft on requirements for Peer protocol X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, all: I have written a draft to describe the requirements for P2PSIP Peer protocol. I hope this contribution could be helpful to get a successful Peer protocol finally. Any comments are appreciated! Thanks! ----- Original Message ----- From: To: Sent: Monday, February 26, 2007 2:50 PM Subject: I-D ACTION:draft-jiang-p2psip-peer-protocol-requirement-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The requirement of P2PSIP Peer protocol > Author(s) : X. Jiang > Filename : draft-jiang-p2psip-peer-protocol-requirement-00.txt > Pages : 18 > Date : 2007-2-26 > > In this draft, we present what P2PSIP should achieve - a distributed > location service. Then we compare the differences between C/S SIP > and P2P SIP and point out that some features which are not > standardized in C/S SIP should be addressed in the P2P SIP case. > After analyzing some problems, some requirements of Peer protocol are > proposed. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jiang-p2psip-peer-protocol-require ment-00.txt -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Feb 26 21:29:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLs5W-0004Ek-Tt; Mon, 26 Feb 2007 21:29:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLs5V-0004EY-Cz for p2psip@ietf.org; Mon, 26 Feb 2007 21:29:09 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLs5T-0005bv-4F for p2psip@ietf.org; Mon, 26 Feb 2007 21:29:09 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE300BTPO701Z@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 27 Feb 2007 10:28:12 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JE300AMAO6ZZ1@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 27 Feb 2007 10:28:12 +0800 (CST) Received: from j36340 ([10.164.5.114]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JE300LODO6WWU@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Feb 2007 10:28:11 +0800 (CST) Date: Tue, 27 Feb 2007 10:28:08 +0800 From: JiangXingFeng Subject: FW: [P2PSIP] Concept draft: Open issues #5 - 8 To: p2psip@ietf.org Message-id: <002001c75a16$eb7210d0$7205a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcdZ02KR3e5j9G48QXmiVfZU11kMXwAQCUtwAADW0ZA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org -- Jiang XingFeng > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Tuesday, February 27, 2007 10:28 AM > To: 'Philip Matthews' > Subject: RE: [P2PSIP] Concept draft: Open issues #5 - 8 > > Hi, Philip: > > Comments are inline! > > -- > Jiang XingFeng > > > -----Original Message----- > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Sent: Tuesday, February 27, 2007 2:23 AM > > To: p2psip@ietf.org > > Subject: [P2PSIP] Concept draft: Open issues #5 - 8 > > > > Folks: > > > > Back in late January I posted four more open issues for the Concepts > > draft. > > There was some discussion on these, and I am going to summarize here > > what I think was agreed to as a result of these discussions. > > > > I plan to make these changes to the draft in the next couple of days. > > > > - Philip > > > > > > Open issue #5: Users vs. Resources vs. Services. > > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html > > ======================================= > > I propose to go with the following description of these. This is my > > original proposal above > > except for the addition of a change suggested by Richard Barnes. > > > > Users are humans. A user may be represented in the P2P Overlay by > > multiple UAs, which represent the various different ways that the > > user may be contacted (e.g., desk phone, mobile). Some of these may > > answer even if the user is not available (e.g., voicemail server). > > > > A service represents something that a peer can do on behalf of > > another peer. Multiple peers may offer the same service. Within a > > service type (e.g., "STUN server"), there may be differentiation > > between the peers on the exact sub-type of the service provided > > (e.g., "STUN server" vs. "STUN server with relay service"). However, > > once the sub-type is selected, the service is identical between > > peers, so which one to contact can be determined by things such as > > net-path efficiency. > > > > Information about a UA, user, or service may be stored in the > > distributed > > database. The information is stored in a "record", which has an > > associated "key" which is used for lookup. > > > > It may be that a P2PSIP Overlay will store other information in the > > distributed database. Generically, we use the term "resource" for > > the information that can be stored in the distributed database. > > > [JiangXingFeng] Basically, I agree with your proposals. In terms of service, I have > something to say. Service is a big concept, and we could define any functions that a > peer could provide as service. So in P2PSIP, we should narrow the scope of service > concept. Maybe we should confine the service which is helpful to SIP like > applications, such as VoIP, IM, presence, etc. > > Another point is that we should differentiate the service provided by the peer itself > and the service provided by the P2PSIP overlay. In draft-willis-p2psip-concepts-03, > we often say peers are providing storage and routing service for other peers. I think > the meaning of storage service, routing service, replication service is different from > the meaning of high level service like stun service, VM service, etc. So, my > suggestion is that we call the service provided by the overlay as function in order to > distinguish these two types of service on the different level. > > > > > > Open issue #6: Data Model vs Service Model > > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html > > ========================================================= > > I propose to add the concept of a Data Model vs a Service Model, > > as described in > > http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 > > and > > http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-01.txt > > Dan Romascanu requested that we come up with different terms, > > and I will try to do that. (Feel free to make suggestions!) > > > [JiangXingFeng] What I really concerns is that how the introduction of Service model > could help. My suggestion is that some examples are needed in the new revision to > explain the benefit from the service model. > > > > > > Open issue #7: Admitting Peer > > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002000.html > > ========================================================= > > I propose to add the terms "Joining Peer" and "Admitting Peer" > > and change "Peer Insertion" to "Peer Admission". > > > [JIangXingFeng] Good job. This classification makes P2PSIP more like a operable > system. > > > > > > Open issue #8: Expressing "Client protocol = SIP?" > > https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002013.html > > ========================================================= > > I propose to rephase this question as "Do clients exist?". > > > [JiangXingFeng] Do you mean that if clients reuse or extend SIP protocol, it is no > need to give the SIP entities a new name "client"? right? > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 27 17:10:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAWb-0000tg-Nc; Tue, 27 Feb 2007 17:10:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAWa-0000tS-Ur for p2psip@ietf.org; Tue, 27 Feb 2007 17:10:20 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMAWY-00005x-Ii for p2psip@ietf.org; Tue, 27 Feb 2007 17:10:20 -0500 Received: from [64.101.172.114] ([64.101.172.114]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l1RLG14t013170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 27 Feb 2007 15:16:03 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: P2PSIP Mailing List From: Dean Willis Date: Tue, 27 Feb 2007 16:10:07 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [P2PSIP] What is a Service? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Starting from Henry's request that P2PSIP differentiate between "service" and "data" models, we seem to have gotten a bit tangled up on the concept of "service". An excellent discussion of the term, from the economic perspective, can be found at: http://en.wikipedia.org/wiki/Service A closer-to-home definition is that of a "Web Service": http://en.wikipedia.org/wiki/Web_service Henry, I believe, was attempting to use the term in a similar vein to "Web Service". He was proposing that the P2P lookup and routing functionality could be provided independently of the real-time call setup functionality. In other words, a "P2P service provider" would provide the distributed database, and we would just use the distributed database as-is to set up calls. We might need to define some new building blocks, but we should make use of the existing blocks where possible. This is an example of what one might call a "Service Oriented Architecture". In this approach, an application loosely-couples various services, possibly adding new services to existing ones, in order to achieve the goal of the application. This application might then be exported as a "service". But this raises questions. Does there need to be a standardized set of "services"? If so, which ones? For example, is "voice mail" a service, and if so, does it need to be standardized? I'd argue that the answer to both of the above is "probably not, at least for now". I'd much rather concentrate on the really reusable prices of functionality we've discussed -- like inserting a peer into an overlay and or routing a request between peers, as the "services" of interest. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 27 18:09:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMBRC-000397-ED; Tue, 27 Feb 2007 18:08:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMBRB-00038Y-2f for p2psip@ietf.org; Tue, 27 Feb 2007 18:08:49 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMBR1-0003Eo-7c for p2psip@ietf.org; Tue, 27 Feb 2007 18:08:49 -0500 Received: from [64.101.172.114] ([64.101.172.114]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l1RMEIlE013429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Feb 2007 16:14:19 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5AFE4517-425B-4E44-8731-CC99CA452AEE@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] What is a Service? Date: Tue, 27 Feb 2007 17:08:24 -0600 To: Dean Willis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Feb 27, 2007, at 4:10 PM, Dean Willis wrote: > I'd much rather concentrate on the really reusable prices of > functionality we've discussed -- like inserting a peer into an > overlay and or routing a request between peers, as the "services" > of interest. Of course, I meant "pieces of functionality". Not "prices". Although my therapist has asked me to discuss this slip in detail during my next session . . . -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Feb 27 20:09:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMDJh-0003d3-TQ; Tue, 27 Feb 2007 20:09:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMC9w-00019f-4p for p2psip@ietf.org; Tue, 27 Feb 2007 18:55:04 -0500 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMC9Z-0004Z4-Gw for p2psip@ietf.org; Tue, 27 Feb 2007 18:55:04 -0500 Received: from source ([192.150.20.142]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Tue, 27 Feb 2007 15:54:02 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l1RNroSd024369; Tue, 27 Feb 2007 15:53:56 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l1RNrkrT006357; Tue, 27 Feb 2007 15:53:50 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 15:53:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] What is a Service? Date: Tue, 27 Feb 2007 15:53:48 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D224E4774@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] What is a Service? Thread-Index: AcdavCTcSwTRISpdREWIxMojFQVkKgAClRTw References: From: "Henry Sinnreich" To: "Dean Willis" , "P2PSIP Mailing List" X-OriginalArrivalTime: 27 Feb 2007 23:53:48.0774 (UTC) FILETIME=[8660E860:01C75ACA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-Mailman-Approved-At: Tue, 27 Feb 2007 20:09:12 -0500 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean, Thanks for keeping the topic alive (the interface to the DHT)! Actually, going right to the original source would be better. Please see: OpenDHT: "A Public DHT Service and Its Uses" by S. Rhea et al.,=20 http://www.intel-research.net/Publications/Pittsburgh/092620050725_326.p df=20 Section 3 on the Interface (to the DHT) says it all. The 3rd interface, the one that provides access to the DHT routing is also very interesting, for example to provide large scale application layer multicast for very large conferences. Thanks again, -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Tuesday, February 27, 2007 4:10 PM To: P2PSIP Mailing List Subject: [P2PSIP] What is a Service? Starting from Henry's request that P2PSIP differentiate between =20 "service" and "data" models, we seem to have gotten a bit tangled up =20 on the concept of "service". An excellent discussion of the term, from the economic perspective, =20 can be found at: http://en.wikipedia.org/wiki/Service A closer-to-home definition is that of a "Web Service": http://en.wikipedia.org/wiki/Web_service Henry, I believe, was attempting to use the term in a similar vein to =20 "Web Service". He was proposing that the P2P lookup and routing =20 functionality could be provided independently of the real-time call =20 setup functionality. In other words, a "P2P service provider" would =20 provide the distributed database, and we would just use the =20 distributed database as-is to set up calls. We might need to define =20 some new building blocks, but we should make use of the existing =20 blocks where possible. This is an example of what one might call a "Service Oriented =20 Architecture". In this approach, an application loosely-couples =20 various services, possibly adding new services to existing ones, in =20 order to achieve the goal of the application. This application might =20 then be exported as a "service". But this raises questions. Does there need to be a standardized set =20 of "services"? If so, which ones? For example, is "voice mail" a service, and if so, does it need to be =20 standardized? I'd argue that the answer to both of the above is "probably not, at =20 least for now". I'd much rather concentrate on the really reusable =20 prices of functionality we've discussed -- like inserting a peer into =20 an overlay and or routing a request between peers, as the "services" =20 of interest. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 28 14:38:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUd9-0007EK-FT; Wed, 28 Feb 2007 14:38:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUd7-0007E9-Sc for p2psip@ietf.org; Wed, 28 Feb 2007 14:38:25 -0500 Received: from mx1-3.spamtrap.magma.ca ([209.217.78.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMUd2-0006PD-KH for p2psip@ietf.org; Wed, 28 Feb 2007 14:38:25 -0500 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx1-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l1SJcHRF031987 for ; Wed, 28 Feb 2007 14:38:17 -0500 Received: from [10.0.1.2] ([24.139.16.154]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l1SJcEMF014478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 28 Feb 2007 14:38:17 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: p2psip@ietf.org From: Philip Matthews Date: Wed, 28 Feb 2007 14:38:07 -0500 X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [P2PSIP] Concepts draft and P2PSIP clients X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org There have been various discussions and proposals for clients over the past few months. First of all, there was the original proposal that was put forth in the -00 version of the Concepts document. In this version, clients associated with (usually just one) peer, with the client acting in a way similar to a SIP UA, and the peer acting in a way similar to a SIP proxy/registrar. In this proposal, clients did not store data for the overlay, nor did they participate in message routing. In this view, clients do not have a "Client ID". Second, there was a proposal by Eric Rescorla. As I understand this proposal, clients are fully meshed into the overlay, but still do not store data for the overlay. However, presumably they do participate in message routing. In this view, clients have a "Peer ID", since they are involved in the DHT. This view has been described as "a peer with bad memory". Third, there has been some private discussion of a model somewhat similar to the first, but where clients DO store data. In essence, a peer can elect to store data on one of its associated clients, rather than in its own memory. In this view, clients do not have a "Client ID" and do not participate in the DHT. I think all three of these views are interesting, albeit contradictory. So I am proposing to include a section in the next revision of the Concepts document that describes these three views. This would mean that the text elsewhere in the document would become somewhat more vague on what a client's role really is. Comments? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 28 15:18:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVFt-0006d8-3F; Wed, 28 Feb 2007 15:18:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVFr-0006Rk-9V for p2psip@ietf.org; Wed, 28 Feb 2007 15:18:27 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMVFp-0004Lt-VU for p2psip@ietf.org; Wed, 28 Feb 2007 15:18:27 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HMVFd-00060N-SK; Wed, 28 Feb 2007 14:18:14 -0600 From: "Brian Rosen" To: "'Philip Matthews'" , Subject: RE: [P2PSIP] Concepts draft and P2PSIP clients Date: Wed, 28 Feb 2007 15:18:22 -0500 Message-ID: <048c01c75b75$99ddf530$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdbcAV+2NDR6Xp9TpmDH4MYzTH7hQABXaYQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Where in this is my model, where clients are all in the overlay, all have an id, all store data, but some of them need to relay messages through another peer? Brian > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, February 28, 2007 2:38 PM > To: p2psip@ietf.org > Subject: [P2PSIP] Concepts draft and P2PSIP clients > > There have been various discussions and proposals > for clients over the past few months. > > First of all, there was the original proposal that was put > forth in the -00 version of the Concepts document. > In this version, clients associated with (usually just one) peer, > with the client acting in a way similar to a SIP UA, > and the peer acting in a way similar to a SIP proxy/registrar. > In this proposal, clients did not store data for the overlay, > nor did they participate in message routing. > In this view, clients do not have a "Client ID". > > Second, there was a proposal by Eric Rescorla. > As I understand this proposal, clients are fully meshed > into the overlay, but still do not store data for the overlay. > However, presumably they do participate in message routing. > In this view, clients have a "Peer ID", since they are involved > in the DHT. This view has been described as > "a peer with bad memory". > > > Third, there has been some private discussion of a model > somewhat similar to the first, but where clients DO store > data. In essence, a peer can elect to store data on one of > its associated clients, rather than in its own memory. > In this view, clients do not have a "Client ID" and do > not participate in the DHT. > > > I think all three of these views are interesting, albeit contradictory. > So I am proposing to include a section in the next revision > of the Concepts document that describes these three views. > This would mean that the text elsewhere in the document > would become somewhat more vague on what a client's role really is. > > > Comments? > > - Philip > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 28 15:26:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVNL-0004k6-8Z; Wed, 28 Feb 2007 15:26:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVNJ-0004ib-2H for p2psip@ietf.org; Wed, 28 Feb 2007 15:26:09 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMVJZ-0004uF-B4 for p2psip@ietf.org; Wed, 28 Feb 2007 15:22:18 -0500 Received: by ug-out-1314.google.com with SMTP id 72so208734ugd for ; Wed, 28 Feb 2007 12:22:16 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z7i27ZlqH2TcwJktMFWNFOL+tllSK9ly7L74OcUAgWgBHHriyRfIu92lJHthZg9et1wCZ8EiD6iSrViCrQYxmoRGqXTUzbQLTjSm/4tqAhnW7rW04ChfS3FmzMA/rp5JBGARafBZzyvVIPlelqHGYj9KyyztRHdnWDmk4DYiD0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G1gZi3H0vymavx+kE8moLDDIhn05u5Tos/3CZab5jEA2iNcGJ/joQcmF7OQ7GSHaZfyLr6SUqqaR9Sgpkx86a+V84R+0xD9on3diL1wL0ygUeUC8+sObip+diFq+4oPMTDDC8O/PNATH7bxVmjqEW0nPjjLAz+Wvv/aulegHtA8= Received: by 10.78.39.16 with SMTP id m16mr81529hum.1172694135919; Wed, 28 Feb 2007 12:22:15 -0800 (PST) Received: by 10.78.174.5 with HTTP; Wed, 28 Feb 2007 12:22:15 -0800 (PST) Message-ID: Date: Wed, 28 Feb 2007 15:22:15 -0500 From: "Bill Mccormick" To: "Philip Matthews" Subject: Re: [P2PSIP] Concepts draft and P2PSIP clients In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I believe there are several good SIP clients out there today (x-lite in particular comes to mind) which should work well in the original proposal... It would encourage adoption if people could continue to use their existing SIP clients with a P2P-SIP infrastructure. Also I believe that the client's user function is logically quite separate from the peer function. Bill On 2/28/07, Philip Matthews wrote: > There have been various discussions and proposals > for clients over the past few months. > > First of all, there was the original proposal that was put > forth in the -00 version of the Concepts document. > In this version, clients associated with (usually just one) peer, > with the client acting in a way similar to a SIP UA, > and the peer acting in a way similar to a SIP proxy/registrar. > In this proposal, clients did not store data for the overlay, > nor did they participate in message routing. > In this view, clients do not have a "Client ID". > > Second, there was a proposal by Eric Rescorla. > As I understand this proposal, clients are fully meshed > into the overlay, but still do not store data for the overlay. > However, presumably they do participate in message routing. > In this view, clients have a "Peer ID", since they are involved > in the DHT. This view has been described as > "a peer with bad memory". > > > Third, there has been some private discussion of a model > somewhat similar to the first, but where clients DO store > data. In essence, a peer can elect to store data on one of > its associated clients, rather than in its own memory. > In this view, clients do not have a "Client ID" and do > not participate in the DHT. > > > I think all three of these views are interesting, albeit contradictory. > So I am proposing to include a section in the next revision > of the Concepts document that describes these three views. > This would mean that the text elsewhere in the document > would become somewhat more vague on what a client's role really is. > > > Comments? > > - Philip > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Bill McCormick _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 28 15:45:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVg3-0000FF-SN; Wed, 28 Feb 2007 15:45:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMVg2-0000F7-TB for p2psip@ietf.org; Wed, 28 Feb 2007 15:45:30 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMVg1-00016B-HQ for p2psip@ietf.org; Wed, 28 Feb 2007 15:45:30 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HMVfo-0004ox-W9; Wed, 28 Feb 2007 14:45:17 -0600 From: "Brian Rosen" To: "'Bill Mccormick'" , "'Philip Matthews'" Subject: RE: [P2PSIP] Concepts draft and P2PSIP clients Date: Wed, 28 Feb 2007 15:45:25 -0500 Message-ID: <049c01c75b79$617f1f80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdbdqoDywo0X7eqRnqlU5CP2tIclgAAdHIw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org To me, this is an "add-on". You create a new proxy-server like entity that is a peer with a sip UA interface and off you go. It has the advantage of being able to use off-the-shelf SIP UAs. It has the disadvantage of not really being peer to peer, it's more like peer domain to peer domain, but so what, it works. I think, though, that it's not subject to standardization. The SIP side is defined, and what we're working on is the p2p side (or d2d from your point of view). Whether the actual multimedia endpoint is inside what we are defining, or connected via standard sip is an implementation issue. I certainly agree that as we define the p2p protocol, we keep this particular deployment in mind. I don't think many of us think of the "client" as an off the shelf sip UA though, or, speaking strictly for myself, my model of a client is a real p2p client, where there is no proxy server equivalent. The client is all there is. We have to deal with relays to get around NAT issues; fact of life, but that is the only thing stopping us from building true transparent p2p clients, as multimedia endpoints on the Internet. Brian > -----Original Message----- > From: Bill Mccormick [mailto:billmcc64@gmail.com] > Sent: Wednesday, February 28, 2007 3:22 PM > To: Philip Matthews > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Concepts draft and P2PSIP clients > > I believe there are several good SIP clients out there today (x-lite > in particular comes to mind) which should work well in the original > proposal... > > It would encourage adoption if people could continue to use their > existing SIP clients with a P2P-SIP infrastructure. Also I believe > that the client's user function is logically quite separate from the > peer function. > > Bill > > On 2/28/07, Philip Matthews wrote: > > There have been various discussions and proposals > > for clients over the past few months. > > > > First of all, there was the original proposal that was put > > forth in the -00 version of the Concepts document. > > In this version, clients associated with (usually just one) peer, > > with the client acting in a way similar to a SIP UA, > > and the peer acting in a way similar to a SIP proxy/registrar. > > In this proposal, clients did not store data for the overlay, > > nor did they participate in message routing. > > In this view, clients do not have a "Client ID". > > > > Second, there was a proposal by Eric Rescorla. > > As I understand this proposal, clients are fully meshed > > into the overlay, but still do not store data for the overlay. > > However, presumably they do participate in message routing. > > In this view, clients have a "Peer ID", since they are involved > > in the DHT. This view has been described as > > "a peer with bad memory". > > > > > > Third, there has been some private discussion of a model > > somewhat similar to the first, but where clients DO store > > data. In essence, a peer can elect to store data on one of > > its associated clients, rather than in its own memory. > > In this view, clients do not have a "Client ID" and do > > not participate in the DHT. > > > > > > I think all three of these views are interesting, albeit contradictory. > > So I am proposing to include a section in the next revision > > of the Concepts document that describes these three views. > > This would mean that the text elsewhere in the document > > would become somewhat more vague on what a client's role really is. > > > > > > Comments? > > > > - Philip > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > -- > Bill McCormick > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 28 16:06:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMW0Q-00029H-7v; Wed, 28 Feb 2007 16:06:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMW0O-00028b-Tc for p2psip@ietf.org; Wed, 28 Feb 2007 16:06:32 -0500 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMVzW-0002p1-Vc for p2psip@ietf.org; Wed, 28 Feb 2007 16:06:32 -0500 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l1SL5X4i017472; Wed, 28 Feb 2007 16:05:33 -0500 Received: from [10.0.1.2] ([24.139.16.154]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id l1SL5UP0003297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Feb 2007 16:05:32 -0500 In-Reply-To: <048c01c75b75$99ddf530$640fa8c0@cis.neustar.com> References: <048c01c75b75$99ddf530$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F158A46-A51C-4930-A84E-2D106F5BE8FA@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Concepts draft and P2PSIP clients Date: Wed, 28 Feb 2007 16:05:29 -0500 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Brian: Your brief description below happens to match exactly the description of a "peer" in Concepts-03. What I think you might be referring to is the super-peer / ordinary- peer approach to NAT Traversal. I will mention this approach in Concepts-04, but it is my impression that we agreed to the alternative approach of treating all peers as equal for NAT Traversal. - Philip On 28-Feb-07, at 15:18 , Brian Rosen wrote: > Where in this is my model, where clients are all in the overlay, > all have an > id, all store data, but some of them need to relay messages through > another > peer? > > Brian > >> -----Original Message----- >> From: Philip Matthews [mailto:philip_matthews@magma.ca] >> Sent: Wednesday, February 28, 2007 2:38 PM >> To: p2psip@ietf.org >> Subject: [P2PSIP] Concepts draft and P2PSIP clients >> >> There have been various discussions and proposals >> for clients over the past few months. >> >> First of all, there was the original proposal that was put >> forth in the -00 version of the Concepts document. >> In this version, clients associated with (usually just one) peer, >> with the client acting in a way similar to a SIP UA, >> and the peer acting in a way similar to a SIP proxy/registrar. >> In this proposal, clients did not store data for the overlay, >> nor did they participate in message routing. >> In this view, clients do not have a "Client ID". >> >> Second, there was a proposal by Eric Rescorla. >> As I understand this proposal, clients are fully meshed >> into the overlay, but still do not store data for the overlay. >> However, presumably they do participate in message routing. >> In this view, clients have a "Peer ID", since they are involved >> in the DHT. This view has been described as >> "a peer with bad memory". >> >> >> Third, there has been some private discussion of a model >> somewhat similar to the first, but where clients DO store >> data. In essence, a peer can elect to store data on one of >> its associated clients, rather than in its own memory. >> In this view, clients do not have a "Client ID" and do >> not participate in the DHT. >> >> >> I think all three of these views are interesting, albeit >> contradictory. >> So I am proposing to include a section in the next revision >> of the Concepts document that describes these three views. >> This would mean that the text elsewhere in the document >> would become somewhat more vague on what a client's role really is. >> >> >> Comments? >> >> - Philip >> >> >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 28 19:11:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYtX-0000n5-I3; Wed, 28 Feb 2007 19:11:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYtS-0000jP-UI for p2psip@ietf.org; Wed, 28 Feb 2007 19:11:35 -0500 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMYt9-000648-NW for p2psip@ietf.org; Wed, 28 Feb 2007 19:11:34 -0500 Received: by nf-out-0910.google.com with SMTP id l36so786668nfa for ; Wed, 28 Feb 2007 16:11:15 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=clGaeu1w+1RpKUEz0oceM4indaBnreKNK/XWcITvYM0+OGlLo3Iu6hMqBAkHSwwAyhV/tp1HaoR16CxoJwmN3t1FC8HRk8yvWKSjjF5zDNwPG8py0kCEYBkimZ+/zs0oTpbMBgKKoGDAIuiQkQGRy8+SqGDZKljmBb7QnVGoZnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=kteyZQB/qfxK8jMnYo3o4OqumOEQFVBzLhYfibxFcbLimElwDr/hwefclL4c/u/GDg6w/MvfTnhE2KTo/K4zoxPUWqR79wAWdlmZjLHu76vn/YZ2+YgFllj4JyWxxsAVYD+8gW+s/i2t4L/hLak9m4c1ows6rqWTZNahsLRQcb0= Received: by 10.82.114.3 with SMTP id m3mr448970buc.1172707491349; Wed, 28 Feb 2007 16:04:51 -0800 (PST) Received: by 10.82.127.17 with HTTP; Wed, 28 Feb 2007 16:04:51 -0800 (PST) Message-ID: <4d4304a00702281604o21b141cfncefdd4887d7e86e9@mail.gmail.com> Date: Wed, 28 Feb 2007 19:04:51 -0500 From: "David A. Bryan" To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Google-Sender-Auth: c5af3ee568feaf15 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [P2PSIP] Agenda Requests X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello all: I wanted to list all the people/drafts that people have *asked* for agenda slots for. This is *NOT* the agenda =96 not all of these things will make the agenda, but I wanted to make sure that I had all the requests. If you wanted time and asked me but I forgot you, or you haven't yet asked for time, but want it, let me know now. If you aren't on the list here, I either don't know you want time or forgot, so let me and Brian know again (offlist, please). We'll be looking at putting an agenda together next week. As mentioned before, except under very special circumstances, we are only giving time to people with an associated draft. Cullen Jennings, draft-jennings-p2psip-security-00 Presenter TBD, draft-willis-p2psip-concepts-04 Philip Matthews, draft-matthews-p2psip-bootstrap-mechanisms-00 Philip Matthews, draft-matthews-p2psip-dsip-nat-traversal-00 Philip Matthews, draft-matthews-p2psip-nats-and-overlays-01 Henry Sinnreich, draft-sinnreich-sip-tools-00 Enrico Marocco, draft-marocco-p2psip-interwork-01 Bruce Lowekamp, dSIP family of drafts (draft-bryan-p2psip-dsip-00, draft-zangrilli-p2psip-dsip-dhtchord-00, draft-lowekamp-p2psip-dsip-security-00, draft-zangrilli-p2psip-dsip-dhtbamboo-00, draft-matthews-p2psip-dsip-nat-traversal-00.txt) Henning Shulzrinne, draft-baset-sipping-p2pcommon-00 If I missed any requests, please let me know ASAP. Thanks. David --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 28 21:25:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMayo-0001YF-VQ; Wed, 28 Feb 2007 21:25:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMayn-0001Xz-B9 for p2psip@ietf.org; Wed, 28 Feb 2007 21:25:13 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMayl-0005L9-Ny for p2psip@ietf.org; Wed, 28 Feb 2007 21:25:13 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE7005Q0DD0N4@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 01 Mar 2007 10:24:36 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JE700MOBDCZFG@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 01 Mar 2007 10:24:36 +0800 (CST) Received: from x18916 ([10.85.204.175]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JE7002D8DCWU5@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 01 Mar 2007 10:24:35 +0800 (CST) Date: Thu, 01 Mar 2007 10:24:32 +0800 From: Peili Xu Subject: RE: [P2PSIP] What is a Service? In-reply-to: To: 'Dean Willis' , 'P2PSIP Mailing List' Message-id: <03f001c75ba8$bf7f1ac0$afcc550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdavCVU/UABrcnpSl++qWO4xTc7IwA7BYMg X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I can't agree more with Dean. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, February 28, 2007 6:10 AM To: P2PSIP Mailing List Subject: [P2PSIP] What is a Service? Starting from Henry's request that P2PSIP differentiate between "service" and "data" models, we seem to have gotten a bit tangled up on the concept of "service". An excellent discussion of the term, from the economic perspective, can be found at: http://en.wikipedia.org/wiki/Service A closer-to-home definition is that of a "Web Service": http://en.wikipedia.org/wiki/Web_service Henry, I believe, was attempting to use the term in a similar vein to "Web Service". He was proposing that the P2P lookup and routing functionality could be provided independently of the real-time call setup functionality. In other words, a "P2P service provider" would provide the distributed database, and we would just use the distributed database as-is to set up calls. We might need to define some new building blocks, but we should make use of the existing blocks where possible. This is an example of what one might call a "Service Oriented Architecture". In this approach, an application loosely-couples various services, possibly adding new services to existing ones, in order to achieve the goal of the application. This application might then be exported as a "service". But this raises questions. Does there need to be a standardized set of "services"? If so, which ones? For example, is "voice mail" a service, and if so, does it need to be standardized? I'd argue that the answer to both of the above is "probably not, at least for now". I'd much rather concentrate on the really reusable prices of functionality we've discussed -- like inserting a peer into an overlay and or routing a request between peers, as the "services" of interest. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Feb 28 22:05:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMbb7-0002bk-AX; Wed, 28 Feb 2007 22:04:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMbb6-0002bf-HY for p2psip@ietf.org; Wed, 28 Feb 2007 22:04:48 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMbb4-0007xQ-RZ for p2psip@ietf.org; Wed, 28 Feb 2007 22:04:48 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE70014SF6S8T@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 01 Mar 2007 11:04:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE700J54F6SQS@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 01 Mar 2007 11:04:04 +0800 (CST) Received: from z60980 ([10.164.5.115]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JE7002PMF6OYM@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 01 Mar 2007 11:04:04 +0800 (CST) Date: Thu, 01 Mar 2007 11:04:00 +0800 From: =?gb2312?B?1cW99bvU?= Subject: RE: [P2PSIP] Concepts draft and P2PSIP clients In-reply-to: <048c01c75b75$99ddf530$640fa8c0@cis.neustar.com> To: 'Brian Rosen' , p2psip@ietf.org Message-id: <000001c75bae$42f38080$7305a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcdbcAV+2NDR6Xp9TpmDH4MYzTH7hQABXaYQAA3OaEA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Brian: On the issues, my private opinion is same with you. There are a large number of clients on the internet, if we can use a = part of memories of these clients, we can story more information than we just = use peers=A1=AF memories. But on another way, if all of clients participate = in message routing, the routing delay will be a long time. So I think = client should not participate in routing. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, March 01, 2007 4:18 AM To: 'Philip Matthews'; p2psip@ietf.org Subject: RE: [P2PSIP] Concepts draft and P2PSIP clients Where in this is my model, where clients are all in the overlay, all = have an id, all store data, but some of them need to relay messages through = another peer? Brian > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, February 28, 2007 2:38 PM > To: p2psip@ietf.org > Subject: [P2PSIP] Concepts draft and P2PSIP clients >=20 > There have been various discussions and proposals > for clients over the past few months. >=20 > First of all, there was the original proposal that was put > forth in the -00 version of the Concepts document. > In this version, clients associated with (usually just one) peer, > with the client acting in a way similar to a SIP UA, > and the peer acting in a way similar to a SIP proxy/registrar. > In this proposal, clients did not store data for the overlay, > nor did they participate in message routing. > In this view, clients do not have a "Client ID". >=20 > Second, there was a proposal by Eric Rescorla. > As I understand this proposal, clients are fully meshed > into the overlay, but still do not store data for the overlay. > However, presumably they do participate in message routing. > In this view, clients have a "Peer ID", since they are involved > in the DHT. This view has been described as > "a peer with bad memory". >=20 >=20 > Third, there has been some private discussion of a model > somewhat similar to the first, but where clients DO store > data. In essence, a peer can elect to store data on one of > its associated clients, rather than in its own memory. > In this view, clients do not have a "Client ID" and do > not participate in the DHT. >=20 >=20 > I think all three of these views are interesting, albeit = contradictory. > So I am proposing to include a section in the next revision > of the Concepts document that describes these three views. > This would mean that the text elsewhere in the document > would become somewhat more vague on what a client's role really is. >=20 >=20 > Comments? >=20 > - Philip >=20 >=20 >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip