From p2psip-bounces@ietf.org Wed Aug 08 03:47:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIgGZ-0005Ie-Az; Wed, 08 Aug 2007 03:47:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIgGX-0005DS-HN for p2psip@ietf.org; Wed, 08 Aug 2007 03:47:37 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIgGW-0007VC-TO for p2psip@ietf.org; Wed, 08 Aug 2007 03:47:37 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMG009KH2YA7G@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 08 Aug 2007 15:46:58 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMG00C5U2Y9F5@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 08 Aug 2007 15:46:58 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMG00EN22Y69Y@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 08 Aug 2007 15:46:57 +0800 (CST) Date: Wed, 08 Aug 2007 15:46:54 +0800 From: JiangXingFeng To: 'P2PSIP Mailing List' Message-id: <000801c7d990$4a4f0880$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfZkCOAgnbmRepAT8ymG8zmPxzawAAAA/QQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [P2PSIP] FW: A question on the data type of ASP 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 Sorry, I forget copy this mail to the P2PSIP community. -- Jiang XingFeng > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Wednesday, August 08, 2007 3:46 PM > To: 'fluffy@cisco.com'; 'jdrosen@cisco.com' > Subject: A question on the data type of ASP > > Hi, > > After I read the ASP draft, I have a question. In this proposal, there is a typed data > concept. DHT algorithms often use a huge hash space and think there is no conflict > when mapping the resource into the target hash space, i,e, resources which have > different strings will have different keys(locus). The resulting key has already > implied the type of the resource. > > Why do you introduce the typed data? Do you think hash conflict will become > inevitable after huge resource will be stored in the overlay and using the type to > resolve this conflict? > > Any reply is appreciated. Thanks in advance. > > Regards! > -- > Jiang XingFeng > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This e-mail and its attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed above. Any > use of the information contained herein in any way (including, but not limited to, total > or partial disclosure, reproduction, or dissemination) by persons other than the > intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the > sender by phone or email immediately and delete it! > > -------------------------------------------------------------------- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Aug 15 15:19:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILOPB-0007TR-6D; Wed, 15 Aug 2007 15:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILOPA-0007TC-Ab for p2psip@ietf.org; Wed, 15 Aug 2007 15:19:44 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILOP9-0006Ur-4Q for p2psip@ietf.org; Wed, 15 Aug 2007 15:19:44 -0400 Received: from home2000 (c-76-21-99-127.hsd1.ca.comcast.net[76.21.99.127]) by comcast.net (alnrmhc11) with SMTP id <20070815191942b1100srgeme>; Wed, 15 Aug 2007 19:19:42 +0000 Message-ID: <008701c7df71$bbfc6f90$030aa8c0@comcast.net> From: "Peter Pan" To: "JiangXingFeng" , "'P2PSIP Mailing List'" References: <000801c7d990$4a4f0880$6905a40a@china.huawei.com> Subject: Re: [P2PSIP] FW: A question on the data type of ASP Date: Wed, 15 Aug 2007 12:23:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 sorry, butt getting cold....^_^ peter ----- Original Message ----- From: "JiangXingFeng" To: "'P2PSIP Mailing List'" Sent: Wednesday, August 08, 2007 12:46 AM Subject: [P2PSIP] FW: A question on the data type of ASP > Sorry, I forget copy this mail to the P2PSIP community. > -- > Jiang XingFeng > > > > -----Original Message----- > > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > > Sent: Wednesday, August 08, 2007 3:46 PM > > To: 'fluffy@cisco.com'; 'jdrosen@cisco.com' > > Subject: A question on the data type of ASP > > > > Hi, > > > > After I read the ASP draft, I have a question. In this proposal, there is > a typed data > > concept. DHT algorithms often use a huge hash space and think there is no > conflict > > when mapping the resource into the target hash space, i,e, resources which > have > > different strings will have different keys(locus). The resulting key has > already > > implied the type of the resource. > > > > Why do you introduce the typed data? Do you think hash conflict will > become > > inevitable after huge resource will be stored in the overlay and using the > type to > > resolve this conflict? > > > > Any reply is appreciated. Thanks in advance. > > > > Regards! > > -- > > Jiang XingFeng > > -------------------------------------------------------------------- > > > > CONFIDENTIALITY NOTICE > > > > This e-mail and its attachments contain confidential information from > HUAWEI, > > which is intended only for the person or entity whose address is listed > above. Any > > use of the information contained herein in any way (including, but not > limited to, total > > or partial disclosure, reproduction, or dissemination) by persons other > than the > > intended recipient(s) is prohibited. If you receive this e-mail in error, > please notify the > > sender by phone or email immediately and delete it! > > > > -------------------------------------------------------------------- > > > > > _______________________________________________ > 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 Thu Aug 16 12:03:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhoR-000313-Ag; Thu, 16 Aug 2007 12:03:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhoP-00030r-7c for p2psip@ietf.org; Thu, 16 Aug 2007 12:03:05 -0400 Received: from smtp45.dc2.safesecureweb.com ([208.112.89.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILhoP-0003Vj-10 for p2psip@ietf.org; Thu, 16 Aug 2007 12:03:05 -0400 Received: from mail42.safesecureweb.com (unknown [10.10.1.126]) by smtp45.dc2.safesecureweb.com (Spam Firewall) with ESMTP id 5AD16273C32 for ; Thu, 16 Aug 2007 12:03:02 -0400 (EDT) MIME-Version: 1.0 Date: Thu, 16 Aug 2007 12:02:13 -0400 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: chayn@imhocorp.com To: p2psip@ietf.org Message-ID: <5c24c1f1a63f45bdb919f43278ea5760@243d6f37501c492689ff234b9e8a35b2> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [P2PSIP] Out of Office X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chayn@imhocorp.com 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,=0D=0A=0D=0AI am out of the office and will be unable to respond to m= essages until Thursday, August 16.=0D=0A=0D=0AClaude _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Aug 16 12:37:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILiLx-0003He-OX; Thu, 16 Aug 2007 12:37:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILiLx-0003FC-7t for p2psip@ietf.org; Thu, 16 Aug 2007 12:37:45 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILiLw-0004Lo-N6 for p2psip@ietf.org; Thu, 16 Aug 2007 12:37:45 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 16 Aug 2007 09:37:44 -0700 X-IronPort-AV: i="4.19,272,1183359600"; d="scan'208"; a="8436504:sNHT23922660" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7GGbiRn012870; Thu, 16 Aug 2007 09:37:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7GGbhF4010712; Thu, 16 Aug 2007 16:37:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:37:43 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:37:43 -0700 Message-ID: <46C47D65.3020807@cisco.com> Date: Thu, 16 Aug 2007 12:37:57 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peter Pan Subject: Re: [P2PSIP] FW: A question on the data type of ASP References: <000801c7d990$4a4f0880$6905a40a@china.huawei.com> <008701c7df71$bbfc6f90$030aa8c0@comcast.net> In-Reply-To: <008701c7df71$bbfc6f90$030aa8c0@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2007 16:37:43.0534 (UTC) FILETIME=[C4E7A0E0:01C7E023] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3245; t=1187282264; x=1188146264; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20FW=3A=20A=20question=20on=20the=20data=20t ype=20of=20ASP |Sender:=20; bh=bVUaAb4b2OwqWN0ocMQwCf9vNrHP8JLvJYmHfSH5v6Q=; b=DO4Gcva3QjJoX7E8smW7E1nq6WaZcHJWeWAJnDiLBRXsaElrrUwjWJwPz+QOkPnlTb/Z14O8 7Rp6WZzwY2qCaigKyocJNFjkfKTea7yz+SbKcOO9v1uDCiFFhdzlpo8fCMtN0uuYWOZ3fiwlbv P80bDmKQfmw2aaKME5Hfefdp4=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 Sorry for the delay in responding here. To answer your question, the purpose of the data types is not to avoid hash collisions. As you say that is not likely to happen anyway. The functionality is there since there are a lot of other things that have to happen in the nodes processing that depend on the data type definition: * authorization rules on who can write it * limits on size * rules on what the type is (i.e., does one user overwrite another?) and so on. -Jonathan R. Peter Pan wrote: > sorry, butt getting cold....^_^ > > peter > ----- Original Message ----- > From: "JiangXingFeng" > To: "'P2PSIP Mailing List'" > Sent: Wednesday, August 08, 2007 12:46 AM > Subject: [P2PSIP] FW: A question on the data type of ASP > > >> Sorry, I forget copy this mail to the P2PSIP community. >> -- >> Jiang XingFeng >> >> >>> -----Original Message----- >>> From: JiangXingFeng [mailto:jiang.x.f@huawei.com] >>> Sent: Wednesday, August 08, 2007 3:46 PM >>> To: 'fluffy@cisco.com'; 'jdrosen@cisco.com' >>> Subject: A question on the data type of ASP >>> >>> Hi, >>> >>> After I read the ASP draft, I have a question. In this proposal, there > is >> a typed data >>> concept. DHT algorithms often use a huge hash space and think there is > no >> conflict >>> when mapping the resource into the target hash space, i,e, resources > which >> have >>> different strings will have different keys(locus). The resulting key > has >> already >>> implied the type of the resource. >>> >>> Why do you introduce the typed data? Do you think hash conflict will >> become >>> inevitable after huge resource will be stored in the overlay and using > the >> type to >>> resolve this conflict? >>> >>> Any reply is appreciated. Thanks in advance. >>> >>> Regards! >>> -- >>> Jiang XingFeng >>> -------------------------------------------------------------------- >>> >>> CONFIDENTIALITY NOTICE >>> >>> This e-mail and its attachments contain confidential information from >> HUAWEI, >>> which is intended only for the person or entity whose address is listed >> above. Any >>> use of the information contained herein in any way (including, but not >> limited to, total >>> or partial disclosure, reproduction, or dissemination) by persons other >> than the >>> intended recipient(s) is prohibited. If you receive this e-mail in > error, >> please notify the >>> sender by phone or email immediately and delete it! >>> >>> -------------------------------------------------------------------- >> >> >> >> _______________________________________________ >> 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Aug 18 19:41:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMXvB-00021A-Ey; Sat, 18 Aug 2007 19:41:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMXvA-000213-6E for p2psip@ietf.org; Sat, 18 Aug 2007 19:41:32 -0400 Received: from mta2.prod1.dngr.net ([216.220.209.221]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMXv9-0003NV-KT for p2psip@ietf.org; Sat, 18 Aug 2007 19:41:31 -0400 Received: from mfe2.prod.danger.com (unknown [10.253.33.100]) by px03.prod1.dngr.org (Postfix) with ESMTP id C848310F2E53 for ; Sat, 18 Aug 2007 16:41:30 -0700 (PDT) Received: from [10.253.33.100] (HELO localhost.localdomain) by mfe2.prod.danger.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1874839843 for p2psip@ietf.org; Sat, 18 Aug 2007 16:41:30 -0700 Date: Sat, 18 Aug 2007 16:41:24 -0700 X-Mailer: Danger Service X-Danger-Send-Id: AAAiEEbHg6oAAYav Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" To: p2psip@ietf.org Mime-Version: 1.0 References: <1187479770.27100397@fd5.dngr.org> From: David Barrett Message-Id: <1187480490.2EDA74A9@fd7.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [P2PSIP] Auth/boot is weakest link X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Barrett 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 Any thoughts on the latest Skype debacle? Generally Skype is held up as justification of the power of p2p voip. However, as clearly evidenced in the past week, a system is only as decentralized as its most centralized link: in this case, bootstrapping and authentication. What's the latest thinking about how p2psip would fare better? While no official position has been taken on the issue, it's been argued that a combination of DNS/mDNS makes a good candidate. (Though technically centralized, it's highly redundant and distributed, as well as decentralized in a legal sense -- especialy when compared to Skype!) What other options are on the table for providing authentication and bootstrapping in a way that's superior to Skype? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Aug 20 05:38:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3i1-0003gj-Fm; Mon, 20 Aug 2007 05:38:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3hz-0003bP-IB for p2psip@ietf.org; Mon, 20 Aug 2007 05:38:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IN3hz-000240-1F for p2psip@ietf.org; Mon, 20 Aug 2007 05:38:03 -0400 Received: (qmail invoked by alias); 20 Aug 2007 09:38:01 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 20 Aug 2007 11:38:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xcAEO7JMxcK3Aj0hhndR3sRpRqvRafptR9P6KX2 xh65RkccXBPgKy Message-ID: <46C960F5.1020201@gmx.net> Date: Mon, 20 Aug 2007 11:37:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Barrett Subject: Re: [P2PSIP] Auth/boot is weakest link References: <1187479770.27100397@fd5.dngr.org> <1187480490.2EDA74A9@fd7.dngr.org> In-Reply-To: <1187480490.2EDA74A9@fd7.dngr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Hi David, could you explain a bit more why you think that mDNS would help to solve the problems Skype faced? When you talk about mDNS then do you have these solutions in mind? http://tools.ietf.org/id/draft-lee-sip-dns-sd-uri-01.txt http://www.xmpp.org/extensions/xep-0174.html Ciao Hannes David Barrett wrote: > Any thoughts on the latest Skype debacle? > > Generally Skype is held up as justification of the power of p2p voip. > However, as clearly evidenced in the past week, a system is only as > decentralized as its most centralized link: in this case, > bootstrapping and authentication. > > What's the latest thinking about how p2psip would fare better? > > While no official position has been taken on the issue, it's been > argued that a combination of DNS/mDNS makes a good candidate. (Though > technically centralized, it's highly redundant and distributed, as > well as decentralized in a legal sense -- especialy when compared to > Skype!) > > What other options are on the table for providing authentication and > bootstrapping in a way that's superior to Skype? > > -david > > _______________________________________________ > 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 Mon Aug 20 10:37:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8NL-0003h4-HG; Mon, 20 Aug 2007 10:37:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8NK-0003gY-UK for p2psip@ietf.org; Mon, 20 Aug 2007 10:37:02 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN8NK-0000wS-H4 for p2psip@ietf.org; Mon, 20 Aug 2007 10:37:02 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IN8NB-0002wb-CE; Mon, 20 Aug 2007 09:36:53 -0500 From: "Brian Rosen" To: "'David Barrett'" , References: <1187479770.27100397@fd5.dngr.org> <1187480490.2EDA74A9@fd7.dngr.org> Subject: RE: [P2PSIP] Auth/boot is weakest link Date: Mon, 20 Aug 2007 10:36:55 -0400 Message-ID: <048201c7e337$91ff69d0$0700a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1187480490.2EDA74A9@fd7.dngr.org> Thread-Index: Acfh8UmCMMb+zsrQTHi2wEPT77X3mwBRT3+Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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: 769a46790fb42fbb0b0cc700c82f7081 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 My model is that the centralized part is the enrollment server. Boostrap and credential check is distributed. You can have the Skype effect if ALL of the nodes that do the function come from the same source, and run the same code. Don't do that. Write a spec and have several implementations. Let the nodes that provide the functions be provided by many individuals or organizations. Authentication, in particular, should be able to be fully distributed. Any peer should be able to authenticate an entity attempting to join the overlay. May need widely distributed CRLs or another mechanism for credential revocation. Bootstrap may not be as widely implemented, but I think this incident highlights the necessity to have multiple implementations and multiple operators of bootstrap nodes. Brian > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] > Sent: Saturday, August 18, 2007 7:41 PM > To: p2psip@ietf.org > Subject: [P2PSIP] Auth/boot is weakest link > > Any thoughts on the latest Skype debacle? > > Generally Skype is held up as justification of the power of p2p voip. > However, as clearly evidenced in the past week, a system is only as > decentralized as its most centralized link: in this case, bootstrapping > and authentication. > > What's the latest thinking about how p2psip would fare better? > > While no official position has been taken on the issue, it's been argued > that a combination of DNS/mDNS makes a good candidate. (Though > technically centralized, it's highly redundant and distributed, as well > as decentralized in a legal sense -- especialy when compared to Skype!) > > What other options are on the table for providing authentication and > bootstrapping in a way that's superior to Skype? > > -david > > _______________________________________________ > 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 Mon Aug 20 15:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDGk-0002fk-Ui; Mon, 20 Aug 2007 15:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDGj-0002fZ-A9 for p2psip@ietf.org; Mon, 20 Aug 2007 15:50:33 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INDGi-0002Of-PE for p2psip@ietf.org; Mon, 20 Aug 2007 15:50:33 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1INDGf-0001Nn-Mp for p2psip@ietf.org; Mon, 20 Aug 2007 14:50:29 -0500 Message-ID: <46C9F20A.9070400@softarmor.com> Date: Mon, 20 Aug 2007 14:56:58 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [P2PSIP] Wired News and AP report Skype taken down by avalanche retsart problem 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's a design lesson we need to learn here. Even without a global power failure, P2P networks are subject to avalanche restarts induced by other sources. This requires designing robust restart characteristics into the overlay. From: http://news.wired.com/dynamic/stories/G/GERMANY_SKYPE_OUTAGE?SITE=WIRE&SECTION=HOME&TEMPLATE=DEFAULT Skype Outage Caused by Microsoft Update By MATT MOORE AP Business Writer FRANKFURT, Germany (AP) -- A two-day outage that left millions of Skype users unable to use the popular Internet phone service was caused by an abnormally high number of restarts after people had downloaded a Windows security update, the company said Monday. The worldwide outage, which began on Thursday and ended on Saturday, left millions of Skype users unable to log on to make phone calls or send instant messages. Luxembourg-based Skype Ltd., part of online auction giant eBay Inc., has more than 220 million users in total but typically has 5 million to 6 million users online at any given time. In January, Skype reported that it had counted 9 million users online at one time. In an update to users on Skype's Heartbeat blog, employee Villu Arak said the disruption was not because of hackers or any other malicious activity. Instead, he said that the disruption "was triggered by a massive restart of our users' computers across the globe within a very short timeframe as they re-booted after receiving a routine set of patches through Windows Update," Arak wrote. Microsoft Corp. released its monthly patches last Tuesday, and many computers are set to automatically download and install them. Installation requires a computer restart. "The high number of restarts affected Skype's network resources. This caused a flood of log-in requests, which, combined with the lack of peer-to-peer network resources, prompted a chain reaction that had a critical impact," Arak wrote. Arak did not blame Microsoft for the troubles and said the outage ultimately rested with Skype. Arak said Skype's network normally has an ability to heal itself in such cases, but a previously unknown glitch in Skype's software prevented that from occurring quickly enough. In a statement, Microsoft described its patch as routine and reiterated that the disruption resulted from a bug in Skype software. Users from Vietnam to Brazil to Germany to the United States had complained they could not log on and make phone calls or send instant messages. The outage was a critical moment for the company, founded in 2003 by Niklas Zennstrom and Janus Friis, and was the first major outage since October 2005 when its service was down only for a few hours. "This disruption was unprecedented in terms of its impact and scope," Arak wrote. "We would like to point out that very few technologies or communications networks today are guaranteed to operate without interruptions." _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Aug 20 15:57:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDNo-0001wA-KC; Mon, 20 Aug 2007 15:57:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDNn-0001vO-0r for p2psip@ietf.org; Mon, 20 Aug 2007 15:57:51 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INDNm-0002bM-2e for p2psip@ietf.org; Mon, 20 Aug 2007 15:57:50 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 20 Aug 2007 12:57:42 -0700 From: "David Barrett" To: "'Hannes Tschofenig'" Subject: RE: [P2PSIP] Auth/boot is weakest link Date: Mon, 20 Aug 2007 12:57:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46C960F5.1020201@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfjDc+Tfl2MC7msQnSL9dFYVU2RDQATZ+uw X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 Message-Id: Well, DNS and mDNS are proven solutions to the problem of resolving names to IP addresses, and thus were tossed out as candidate solutions for resolving SIP names to UA IP addresses. In summary it'd work like this: 1) Users purchase DNS names from any registrar supporting dynamic DNS 2) When you install a SIP UA, you plug in your domain name 3) When your UA starts up, it updates your DNS name to resolve to your IP 4) Furthermore, it listens on the mDNS port for attempts to resolve your DNS 5) When you call me, your UA just resolves my DNS name to get my IP 6) If that fails, it also tries an mDNS broadcast to see if we're on a LAN The result is you get authentication (performed by the DNS registrar) and rendezvous (performed by DNS/mDNS) without depending upon any single provider: rather than Skype, Inc. being wholly responsible for (and having complete control over) all P2P calls, every user has the legal and technical right to switch entirely to a different provider. It's still "centralized" in the sense that it depends upon centrally hosted servers, but it's "distributed" between many technical and legal entities. To give an example: 1) I purchase "quinthar.com" from any dynamic-DNS registrar [1] 2) I install my SIP UA and tell it my name is "dbarrett.quinthar.com" 3) On startup, it figures out my latest IP address, and uses dynamic DNS to update the record for "dbarrett.quinthar.com" to resolve to my laptop. 4) Likewise, it listens on the mDNS port to see if anybody tries to resolve "dbarrett.quinthar.com" 5) When you call me, your UA does a totally-standard DNS resolve on "dbarrett.quinthar.com" and comes up with my laptop's IP address 6) Alternatively, if we're on an ad-hoc network in the middle of a desert and for some reason yelling is insufficient, you broadcast an mDNS request on the WLAN for "dbarrett.quinthar.com" and my UA responds with my WLAN IP address. At any point, you or I can change our DNS registrars and the system continues to function as normal. Indeed, even if the provider of our SIP software (eg, Skype) goes out of business or is taken over by a malevolent force, it has absolutely no knowledge of or control over our calls. [1] http://www.dmoz.org/Computers/Software/Internet/Servers/Address_Management/D ynamic_DNS_Services/ We had a *long* discussion on this last year, with Adam Fisk first suggesting the use of dynamic DNS: http://www1.ietf.org/mail-archive/web/p2psip/current/msg01632.html And then Matthew Kaufman suggesting adding mDNS to the mix: http://www1.ietf.org/mail-archive/web/p2psip/current/msg01688.html I summarized how the combination of the two (I didn't know about mDNS at the time, so I was theorizing some "P2P-DNS") effectively cover all the P2PSIP use cases, without all the hassle of a DHT: http://www1.ietf.org/mail-archive/web/p2psip/current/msg01679.html Now, that's all background. As for how this would help Skype, that's not entirely clear given it's not clear what precise problem Skype suffered. Indeed, their explanation that it was due to a massive restart surge triggered by Windows Update seems really unlikely to me. But, assuming that's true, the system above would fare much better because it is geographically distributed over many more servers, managed by a variety of entirely distinct legal entities, and constructed from a wide diversity of hardware and software. It uses standard, open protocols, all of which already exist today and have been proven at scale. It works as well from your office as it does in a post-Katrina disaster zone. Anyway, now you've got me riled up talking about it, but it probably isn't useful to revisit and rehash the former inconclusive debate. Regardless, the reason I brought it up is I'm curious what other options are on the table for bootstrapping/authentication/rendezvous. I've mentioned dynamic-DNS/mDNS and provided some summary around that. Can you provide some summary around alternative solutions? Brian Rosen put forward some general guidelines and requirements around a solution (which, incidentally, I think the above dynDNS/mDNS solution meets). Brian -- Can you give any more detail on this? -david PS: I haven't read the drafts you mentioned; I'll take a look but they look good at first glance! > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, August 20, 2007 2:38 AM > To: David Barrett > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Auth/boot is weakest link > > Hi David, > > could you explain a bit more why you think that mDNS would help to solve > the problems Skype faced? > > When you talk about mDNS then do you have these solutions in mind? > http://tools.ietf.org/id/draft-lee-sip-dns-sd-uri-01.txt > http://www.xmpp.org/extensions/xep-0174.html > > Ciao > Hannes > > David Barrett wrote: > > Any thoughts on the latest Skype debacle? > > > > Generally Skype is held up as justification of the power of p2p voip. > > However, as clearly evidenced in the past week, a system is only as > > decentralized as its most centralized link: in this case, > > bootstrapping and authentication. > > > > What's the latest thinking about how p2psip would fare better? > > > > While no official position has been taken on the issue, it's been > > argued that a combination of DNS/mDNS makes a good candidate. (Though > > technically centralized, it's highly redundant and distributed, as > > well as decentralized in a legal sense -- especialy when compared to > > Skype!) > > > > What other options are on the table for providing authentication and > > bootstrapping in a way that's superior to Skype? > > > > -david > > > > _______________________________________________ > > 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 Mon Aug 20 16:02:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDS9-0005SW-Lp; Mon, 20 Aug 2007 16:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDS9-0005SR-4g for p2psip@ietf.org; Mon, 20 Aug 2007 16:02:21 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INDS7-000864-Ti for p2psip@ietf.org; Mon, 20 Aug 2007 16:02:21 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7KK2G919932; Mon, 20 Aug 2007 20:02:16 GMT 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] Wired News and AP report Skype taken down by avalanche retsart problem Date: Mon, 20 Aug 2007 15:02:14 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11AEC002@zrc2hxm0.corp.nortel.com> In-Reply-To: <46C9F20A.9070400@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Wired News and AP report Skype taken down by avalanche retsart problem Thread-Index: AcfjY2Z9eSYF3DANT7m48p7et0iDrgAAJq+g References: <46C9F20A.9070400@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "P2PSIP Mailing List" X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 There are quite many messages from this meltdown: - Security by obscurity is bad - Relying on single source proprietary implementations is bad - Believing in a "magic box" to solve all problems is bad=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, August 20, 2007 12:57 > To: P2PSIP Mailing List > Subject: [P2PSIP] Wired News and AP report Skype taken down=20 > by avalanche retsart problem >=20 > There's a design lesson we need to learn here. Even without a=20 > global power failure, P2P networks are subject to avalanche=20 > restarts induced by other sources. This requires designing=20 > robust restart characteristics into the overlay. >=20 >=20 > From: >=20 > http://news.wired.com/dynamic/stories/G/GERMANY_SKYPE_OUTAGE?S ITE=3DWIRE&SECTION=3DHOME&TEMPLATE=3DDEFAULT >=20 >=20 > Skype Outage Caused by Microsoft Update >=20 > By MATT MOORE > AP Business Writer >=20 > FRANKFURT, Germany (AP) -- A two-day outage that left=20 > millions of Skype users unable to use the popular Internet=20 > phone service was caused by an abnormally high number of=20 > restarts after people had downloaded a Windows security=20 > update, the company said Monday. >=20 > The worldwide outage, which began on Thursday and ended on=20 > Saturday, left millions of Skype users unable to log on to=20 > make phone calls or send instant messages. >=20 > Luxembourg-based Skype Ltd., part of online auction giant=20 > eBay Inc., has more than 220 million users in total but=20 > typically has 5 million to 6 million users online at any=20 > given time. In January, Skype reported that it had counted 9=20 > million users online at one time. >=20 > In an update to users on Skype's Heartbeat blog, employee=20 > Villu Arak said the disruption was not because of hackers or=20 > any other malicious activity. >=20 > Instead, he said that the disruption "was triggered by a=20 > massive restart of our users' computers across the globe=20 > within a very short timeframe as they re-booted after=20 > receiving a routine set of patches through Windows Update,"=20 > Arak wrote. >=20 > Microsoft Corp. released its monthly patches last Tuesday,=20 > and many computers are set to automatically download and install them. > Installation requires a computer restart. >=20 > "The high number of restarts affected Skype's network=20 > resources. This caused a flood of log-in requests, which,=20 > combined with the lack of peer-to-peer network resources,=20 > prompted a chain reaction that had a critical impact," Arak wrote. >=20 > Arak did not blame Microsoft for the troubles and said the=20 > outage ultimately rested with Skype. Arak said Skype's=20 > network normally has an ability to heal itself in such cases,=20 > but a previously unknown glitch in Skype's software prevented=20 > that from occurring quickly enough. >=20 > In a statement, Microsoft described its patch as routine and=20 > reiterated that the disruption resulted from a bug in Skype software. >=20 > Users from Vietnam to Brazil to Germany to the United States=20 > had complained they could not log on and make phone calls or=20 > send instant messages. >=20 > The outage was a critical moment for the company, founded in=20 > 2003 by Niklas Zennstrom and Janus Friis, and was the first=20 > major outage since October 2005 when its service was down=20 > only for a few hours. >=20 > "This disruption was unprecedented in terms of its impact and scope," > Arak wrote. "We would like to point out that very few=20 > technologies or communications networks today are guaranteed=20 > to operate without interruptions." >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Aug 20 16:14:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDdQ-0005yu-Gm; Mon, 20 Aug 2007 16:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDdP-0005yo-Ui for p2psip@ietf.org; Mon, 20 Aug 2007 16:13:59 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INDdO-0008ON-CC for p2psip@ietf.org; Mon, 20 Aug 2007 16:13:59 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 20 Aug 2007 13:13:50 -0700 From: "David Barrett" To: "'Francois Audet'" , "'Dean Willis'" , "'P2PSIP Mailing List'" Subject: RE: [P2PSIP] Wired News and AP report Skype taken down by avalancheretsart problem Date: Mon, 20 Aug 2007 13:13:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11AEC002@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfjY2Z9eSYF3DANT7m48p7et0iDrgAAJq+gAABabKA= X-Spam-Score: 0.3 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 Message-Id: What I don't understand is why it took *2 days* to get back up and running. I mean, let's say all 9M Skype users restarted at the exact same time. If it takes 2 days for that many clients to log in, that's only 52 logins per second: certainly there's something else going on here. (As comparison, consider how many logins per second Hotmail must handle?) It seems to me that the overload problem cannot possibly be due to a lack of central authentication capacity -- that's not the weak link in this chain. It seems more probable that the problem is actually due to the P2P network itself: that their DHT (or whatever they use) is able to handle minor blips and growth, but given a massive churn event just died entirely. (I'm visualizing how you can slowly pour vinegar into oil and it stays in a big pool, but if you splash it in it explodes into a thousand tiny, individual pools that can't reform.) If that's true, I'm curious: what's the benefit that Skype is getting from putting rendezvous functionality into a P2P datastructure rather than just handling it centrally? -david > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, August 20, 2007 1:02 PM > To: Dean Willis; P2PSIP Mailing List > Subject: RE: [P2PSIP] Wired News and AP report Skype taken down by > avalancheretsart problem > > There are quite many messages from this meltdown: > > - Security by obscurity is bad > > - Relying on single source proprietary implementations is bad > > - Believing in a "magic box" to solve all problems is bad > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Monday, August 20, 2007 12:57 > > To: P2PSIP Mailing List > > Subject: [P2PSIP] Wired News and AP report Skype taken down > > by avalanche retsart problem > > > > There's a design lesson we need to learn here. Even without a > > global power failure, P2P networks are subject to avalanche > > restarts induced by other sources. This requires designing > > robust restart characteristics into the overlay. > > > > > > From: > > > > http://news.wired.com/dynamic/stories/G/GERMANY_SKYPE_OUTAGE?S > ITE=WIRE&SECTION=HOME&TEMPLATE=DEFAULT > > > > > > Skype Outage Caused by Microsoft Update > > > > By MATT MOORE > > AP Business Writer > > > > FRANKFURT, Germany (AP) -- A two-day outage that left > > millions of Skype users unable to use the popular Internet > > phone service was caused by an abnormally high number of > > restarts after people had downloaded a Windows security > > update, the company said Monday. > > > > The worldwide outage, which began on Thursday and ended on > > Saturday, left millions of Skype users unable to log on to > > make phone calls or send instant messages. > > > > Luxembourg-based Skype Ltd., part of online auction giant > > eBay Inc., has more than 220 million users in total but > > typically has 5 million to 6 million users online at any > > given time. In January, Skype reported that it had counted 9 > > million users online at one time. > > > > In an update to users on Skype's Heartbeat blog, employee > > Villu Arak said the disruption was not because of hackers or > > any other malicious activity. > > > > Instead, he said that the disruption "was triggered by a > > massive restart of our users' computers across the globe > > within a very short timeframe as they re-booted after > > receiving a routine set of patches through Windows Update," > > Arak wrote. > > > > Microsoft Corp. released its monthly patches last Tuesday, > > and many computers are set to automatically download and install them. > > Installation requires a computer restart. > > > > "The high number of restarts affected Skype's network > > resources. This caused a flood of log-in requests, which, > > combined with the lack of peer-to-peer network resources, > > prompted a chain reaction that had a critical impact," Arak wrote. > > > > Arak did not blame Microsoft for the troubles and said the > > outage ultimately rested with Skype. Arak said Skype's > > network normally has an ability to heal itself in such cases, > > but a previously unknown glitch in Skype's software prevented > > that from occurring quickly enough. > > > > In a statement, Microsoft described its patch as routine and > > reiterated that the disruption resulted from a bug in Skype software. > > > > Users from Vietnam to Brazil to Germany to the United States > > had complained they could not log on and make phone calls or > > send instant messages. > > > > The outage was a critical moment for the company, founded in > > 2003 by Niklas Zennstrom and Janus Friis, and was the first > > major outage since October 2005 when its service was down > > only for a few hours. > > > > "This disruption was unprecedented in terms of its impact and scope," > > Arak wrote. "We would like to point out that very few > > technologies or communications networks today are guaranteed > > to operate without interruptions." > > > > _______________________________________________ > > 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 From p2psip-bounces@ietf.org Mon Aug 20 16:22:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDle-0003uP-C3; Mon, 20 Aug 2007 16:22:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDld-0003nZ-7S for p2psip@ietf.org; Mon, 20 Aug 2007 16:22:29 -0400 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INDlb-00006F-UQ for p2psip@ietf.org; Mon, 20 Aug 2007 16:22:29 -0400 Received: from home2000 (c-76-21-99-127.hsd1.ca.comcast.net[76.21.99.127]) by comcast.net (alnrmhc15) with SMTP id <20070820202226b1500bggu0e>; Mon, 20 Aug 2007 20:22:27 +0000 Message-ID: <003c01c7e368$5a9533e0$030aa8c0@comcast.net> From: "Peter Pan" To: "David Barrett" , "'Hannes Tschofenig'" References: Subject: Re: [P2PSIP] Auth/boot is weakest link Date: Mon, 20 Aug 2007 13:26:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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 u mean that we should turn our heads away from dht technologies? another question, can existing dns infrastructure carry millions or even billions of individual sip ua's without overhaul? thank u. pp ----- Original Message ----- From: "David Barrett" To: "'Hannes Tschofenig'" Cc: Sent: Monday, August 20, 2007 12:57 PM Subject: RE: [P2PSIP] Auth/boot is weakest link > Well, DNS and mDNS are proven solutions to the problem of resolving names to > IP addresses, and thus were tossed out as candidate solutions for resolving > SIP names to UA IP addresses. In summary it'd work like this: > > 1) Users purchase DNS names from any registrar supporting dynamic DNS > 2) When you install a SIP UA, you plug in your domain name > 3) When your UA starts up, it updates your DNS name to resolve to your IP > 4) Furthermore, it listens on the mDNS port for attempts to resolve your DNS > 5) When you call me, your UA just resolves my DNS name to get my IP > 6) If that fails, it also tries an mDNS broadcast to see if we're on a LAN > > The result is you get authentication (performed by the DNS registrar) and > rendezvous (performed by DNS/mDNS) without depending upon any single > provider: rather than Skype, Inc. being wholly responsible for (and having > complete control over) all P2P calls, every user has the legal and technical > right to switch entirely to a different provider. It's still "centralized" > in the sense that it depends upon centrally hosted servers, but it's > "distributed" between many technical and legal entities. > > To give an example: > 1) I purchase "quinthar.com" from any dynamic-DNS registrar [1] > 2) I install my SIP UA and tell it my name is "dbarrett.quinthar.com" > 3) On startup, it figures out my latest IP address, and uses dynamic DNS to > update the record for "dbarrett.quinthar.com" to resolve to my laptop. > 4) Likewise, it listens on the mDNS port to see if anybody tries to resolve > "dbarrett.quinthar.com" > 5) When you call me, your UA does a totally-standard DNS resolve on > "dbarrett.quinthar.com" and comes up with my laptop's IP address > 6) Alternatively, if we're on an ad-hoc network in the middle of a desert > and for some reason yelling is insufficient, you broadcast an mDNS request > on the WLAN for "dbarrett.quinthar.com" and my UA responds with my WLAN IP > address. > > At any point, you or I can change our DNS registrars and the system > continues to function as normal. Indeed, even if the provider of our SIP > software (eg, Skype) goes out of business or is taken over by a malevolent > force, it has absolutely no knowledge of or control over our calls. > > [1] > http://www.dmoz.org/Computers/Software/Internet/Servers/Address_Management/D > ynamic_DNS_Services/ > > > We had a *long* discussion on this last year, with Adam Fisk first > suggesting the use of dynamic DNS: > > http://www1.ietf.org/mail-archive/web/p2psip/current/msg01632.html > > And then Matthew Kaufman suggesting adding mDNS to the mix: > > http://www1.ietf.org/mail-archive/web/p2psip/current/msg01688.html > > I summarized how the combination of the two (I didn't know about mDNS at the > time, so I was theorizing some "P2P-DNS") effectively cover all the P2PSIP > use cases, without all the hassle of a DHT: > > http://www1.ietf.org/mail-archive/web/p2psip/current/msg01679.html > > > Now, that's all background. As for how this would help Skype, that's not > entirely clear given it's not clear what precise problem Skype suffered. > Indeed, their explanation that it was due to a massive restart surge > triggered by Windows Update seems really unlikely to me. > > But, assuming that's true, the system above would fare much better because > it is geographically distributed over many more servers, managed by a > variety of entirely distinct legal entities, and constructed from a wide > diversity of hardware and software. It uses standard, open protocols, all > of which already exist today and have been proven at scale. It works as > well from your office as it does in a post-Katrina disaster zone. > > Anyway, now you've got me riled up talking about it, but it probably isn't > useful to revisit and rehash the former inconclusive debate. > > Regardless, the reason I brought it up is I'm curious what other options are > on the table for bootstrapping/authentication/rendezvous. I've mentioned > dynamic-DNS/mDNS and provided some summary around that. Can you provide > some summary around alternative solutions? > > Brian Rosen put forward some general guidelines and requirements around a > solution (which, incidentally, I think the above dynDNS/mDNS solution > meets). Brian -- Can you give any more detail on this? > > -david > > PS: I haven't read the drafts you mentioned; I'll take a look but they look > good at first glance! > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Monday, August 20, 2007 2:38 AM > > To: David Barrett > > Cc: p2psip@ietf.org > > Subject: Re: [P2PSIP] Auth/boot is weakest link > > > > Hi David, > > > > could you explain a bit more why you think that mDNS would help to solve > > the problems Skype faced? > > > > When you talk about mDNS then do you have these solutions in mind? > > http://tools.ietf.org/id/draft-lee-sip-dns-sd-uri-01.txt > > http://www.xmpp.org/extensions/xep-0174.html > > > > Ciao > > Hannes > > > > David Barrett wrote: > > > Any thoughts on the latest Skype debacle? > > > > > > Generally Skype is held up as justification of the power of p2p voip. > > > However, as clearly evidenced in the past week, a system is only as > > > decentralized as its most centralized link: in this case, > > > bootstrapping and authentication. > > > > > > What's the latest thinking about how p2psip would fare better? > > > > > > While no official position has been taken on the issue, it's been > > > argued that a combination of DNS/mDNS makes a good candidate. (Though > > > technically centralized, it's highly redundant and distributed, as > > > well as decentralized in a legal sense -- especialy when compared to > > > Skype!) > > > > > > What other options are on the table for providing authentication and > > > bootstrapping in a way that's superior to Skype? > > > > > > -david > > > > > > _______________________________________________ > > > 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 From p2psip-bounces@ietf.org Mon Aug 20 17:09:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INEUv-00029t-Ne; Mon, 20 Aug 2007 17:09:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INEUt-00029Z-Pe for p2psip@ietf.org; Mon, 20 Aug 2007 17:09:15 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INEUs-0000xB-J1 for p2psip@ietf.org; Mon, 20 Aug 2007 17:09:15 -0400 Received: from home2000 (c-76-21-99-127.hsd1.ca.comcast.net[76.21.99.127]) by comcast.net (alnrmhc16) with SMTP id <20070820210913b1600s2v98e>; Mon, 20 Aug 2007 21:09:13 +0000 Message-ID: <007301c7e36e$e36b8290$030aa8c0@comcast.net> From: "Peter Pan" To: "Francois Audet" , "Dean Willis" , "P2PSIP Mailing List" References: <46C9F20A.9070400@softarmor.com> <1ECE0EB50388174790F9694F77522CCF11AEC002@zrc2hxm0.corp.nortel.com> Subject: Re: [P2PSIP] Wired News and AP report Skype taken down by avalancheretsart problem Date: Mon, 20 Aug 2007 14:12:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 these msgs seem a "conversation" in chinese. ho~ho~pp ----- Original Message ----- From: "Francois Audet" To: "Dean Willis" ; "P2PSIP Mailing List" Sent: Monday, August 20, 2007 1:02 PM Subject: RE: [P2PSIP] Wired News and AP report Skype taken down by avalancheretsart problem There are quite many messages from this meltdown: - Security by obscurity is bad - Relying on single source proprietary implementations is bad - Believing in a "magic box" to solve all problems is bad > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, August 20, 2007 12:57 > To: P2PSIP Mailing List > Subject: [P2PSIP] Wired News and AP report Skype taken down > by avalanche retsart problem > > There's a design lesson we need to learn here. Even without a > global power failure, P2P networks are subject to avalanche > restarts induced by other sources. This requires designing > robust restart characteristics into the overlay. > > > From: > > http://news.wired.com/dynamic/stories/G/GERMANY_SKYPE_OUTAGE?S ITE=WIRE&SECTION=HOME&TEMPLATE=DEFAULT > > > Skype Outage Caused by Microsoft Update > > By MATT MOORE > AP Business Writer > > FRANKFURT, Germany (AP) -- A two-day outage that left > millions of Skype users unable to use the popular Internet > phone service was caused by an abnormally high number of > restarts after people had downloaded a Windows security > update, the company said Monday. > > The worldwide outage, which began on Thursday and ended on > Saturday, left millions of Skype users unable to log on to > make phone calls or send instant messages. > > Luxembourg-based Skype Ltd., part of online auction giant > eBay Inc., has more than 220 million users in total but > typically has 5 million to 6 million users online at any > given time. In January, Skype reported that it had counted 9 > million users online at one time. > > In an update to users on Skype's Heartbeat blog, employee > Villu Arak said the disruption was not because of hackers or > any other malicious activity. > > Instead, he said that the disruption "was triggered by a > massive restart of our users' computers across the globe > within a very short timeframe as they re-booted after > receiving a routine set of patches through Windows Update," > Arak wrote. > > Microsoft Corp. released its monthly patches last Tuesday, > and many computers are set to automatically download and install them. > Installation requires a computer restart. > > "The high number of restarts affected Skype's network > resources. This caused a flood of log-in requests, which, > combined with the lack of peer-to-peer network resources, > prompted a chain reaction that had a critical impact," Arak wrote. > > Arak did not blame Microsoft for the troubles and said the > outage ultimately rested with Skype. Arak said Skype's > network normally has an ability to heal itself in such cases, > but a previously unknown glitch in Skype's software prevented > that from occurring quickly enough. > > In a statement, Microsoft described its patch as routine and > reiterated that the disruption resulted from a bug in Skype software. > > Users from Vietnam to Brazil to Germany to the United States > had complained they could not log on and make phone calls or > send instant messages. > > The outage was a critical moment for the company, founded in > 2003 by Niklas Zennstrom and Janus Friis, and was the first > major outage since October 2005 when its service was down > only for a few hours. > > "This disruption was unprecedented in terms of its impact and scope," > Arak wrote. "We would like to point out that very few > technologies or communications networks today are guaranteed > to operate without interruptions." > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Aug 20 18:40:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFuu-0007dA-RQ; Mon, 20 Aug 2007 18:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFut-0007cq-V6 for p2psip@ietf.org; Mon, 20 Aug 2007 18:40:11 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INFus-00047E-O2 for p2psip@ietf.org; Mon, 20 Aug 2007 18:40:11 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l7KMe6Ng009659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Aug 2007 18:40:09 -0400 (EDT) Date: Mon, 20 Aug 2007 18:40:06 -0400 (EDT) From: Salman Abdul Baset To: Francois Audet Subject: RE: [P2PSIP] Wired News and AP report Skype taken down by avalanche retsart problem In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11AEC002@zrc2hxm0.corp.nortel.com> Message-ID: References: <46C9F20A.9070400@softarmor.com> <1ECE0EB50388174790F9694F77522CCF11AEC002@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -0.7 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Frankly, the only conclusion I will draw from this article is that churn mitigation is not a trivial problem. As Dean mentioned, the peer protocol should provide mechanisms to be robust against churn and must assume the worst churn scenario. The worst scenario is that the majority of nodes can (and will) die at the same time. On Mon, 20 Aug 2007, Francois Audet wrote: > There are quite many messages from this meltdown: > > - Security by obscurity is bad > > - Relying on single source proprietary implementations is bad > > - Believing in a "magic box" to solve all problems is bad > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Monday, August 20, 2007 12:57 >> To: P2PSIP Mailing List >> Subject: [P2PSIP] Wired News and AP report Skype taken down >> by avalanche retsart problem >> >> There's a design lesson we need to learn here. Even without a >> global power failure, P2P networks are subject to avalanche >> restarts induced by other sources. This requires designing >> robust restart characteristics into the overlay. >> >> >> From: >> >> http://news.wired.com/dynamic/stories/G/GERMANY_SKYPE_OUTAGE?S > ITE=WIRE&SECTION=HOME&TEMPLATE=DEFAULT >> >> >> Skype Outage Caused by Microsoft Update >> >> By MATT MOORE >> AP Business Writer >> >> FRANKFURT, Germany (AP) -- A two-day outage that left >> millions of Skype users unable to use the popular Internet >> phone service was caused by an abnormally high number of >> restarts after people had downloaded a Windows security >> update, the company said Monday. >> >> The worldwide outage, which began on Thursday and ended on >> Saturday, left millions of Skype users unable to log on to >> make phone calls or send instant messages. >> >> Luxembourg-based Skype Ltd., part of online auction giant >> eBay Inc., has more than 220 million users in total but >> typically has 5 million to 6 million users online at any >> given time. In January, Skype reported that it had counted 9 >> million users online at one time. >> >> In an update to users on Skype's Heartbeat blog, employee >> Villu Arak said the disruption was not because of hackers or >> any other malicious activity. >> >> Instead, he said that the disruption "was triggered by a >> massive restart of our users' computers across the globe >> within a very short timeframe as they re-booted after >> receiving a routine set of patches through Windows Update," >> Arak wrote. >> >> Microsoft Corp. released its monthly patches last Tuesday, >> and many computers are set to automatically download and install them. >> Installation requires a computer restart. >> >> "The high number of restarts affected Skype's network >> resources. This caused a flood of log-in requests, which, >> combined with the lack of peer-to-peer network resources, >> prompted a chain reaction that had a critical impact," Arak wrote. >> >> Arak did not blame Microsoft for the troubles and said the >> outage ultimately rested with Skype. Arak said Skype's >> network normally has an ability to heal itself in such cases, >> but a previously unknown glitch in Skype's software prevented >> that from occurring quickly enough. >> >> In a statement, Microsoft described its patch as routine and >> reiterated that the disruption resulted from a bug in Skype software. >> >> Users from Vietnam to Brazil to Germany to the United States >> had complained they could not log on and make phone calls or >> send instant messages. >> >> The outage was a critical moment for the company, founded in >> 2003 by Niklas Zennstrom and Janus Friis, and was the first >> major outage since October 2005 when its service was down >> only for a few hours. >> >> "This disruption was unprecedented in terms of its impact and scope," >> Arak wrote. "We would like to point out that very few >> technologies or communications networks today are guaranteed >> to operate without interruptions." >> >> _______________________________________________ >> 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 From p2psip-bounces@ietf.org Mon Aug 20 18:47:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ING1W-0004SG-8O; Mon, 20 Aug 2007 18:47:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ING1V-0004SA-D1 for p2psip@ietf.org; Mon, 20 Aug 2007 18:47:01 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ING1U-0004H5-3c for p2psip@ietf.org; Mon, 20 Aug 2007 18:47:01 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 20 Aug 2007 15:46:57 -0700 From: "David Barrett" To: "'Peter Pan'" , "'Hannes Tschofenig'" Subject: RE: [P2PSIP] Auth/boot is weakest link Date: Mon, 20 Aug 2007 15:46:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <003c01c7e368$5a9533e0$030aa8c0@comcast.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfjaSXiDNojikRPSpiCQ2QJvtVcBwAENn/A X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Message-Id: > -----Original Message----- > From: Peter Pan > Subject: Re: [P2PSIP] Auth/boot is weakest link > > do u mean that we should turn our heads away from dht technologies? No, whether or not to use a DHT is another discussion entirely. However, even with a DHT used for rendezvous purposes (which I believe is the intent of P2PSIP), some other service (non-DHT?) must exist for authentication and bootstrapping into the network. It looked like it was the authentication/bootstrapping services that failed in the Skype case (though now it's looking like a problem in the p2p layer), and thus I'm curious what solutions are on the table for authentication and bootstrapping. > another question, can existing dns infrastructure carry millions or even > billions of individual sip ua's without overhaul? I don't see why it couldn't, at least by the time there are truly millions or billions of individual SIP UA's using it. Recall -- even Skype only has 9M simultaneous, and that makes up nearly 100% of all internet-based VoIP. It'll be a long, long time before P2PSIP has anything similar to those numbers. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Aug 20 20:01:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INHBI-0003Tx-Ig; Mon, 20 Aug 2007 20:01:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INHBH-0003Te-Mt for p2psip@ietf.org; Mon, 20 Aug 2007 20:01:11 -0400 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INHBH-0001YA-Ay for p2psip@ietf.org; Mon, 20 Aug 2007 20:01:11 -0400 Received: from home2000 (c-76-21-99-127.hsd1.ca.comcast.net[76.21.99.127]) by comcast.net (alnrmhc11) with SMTP id <20070821000110b1100srh7te>; Tue, 21 Aug 2007 00:01:10 +0000 Message-ID: <00fb01c7e386$e8aad0e0$030aa8c0@comcast.net> From: "Peter Pan" To: "David Barrett" , "'Hannes Tschofenig'" Subject: Re: [P2PSIP] Auth/boot is weakest link Date: Mon, 20 Aug 2007 17:04:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Spam-Score: 2.2 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 thought you were recommending dns for resolving addresses of endpoints instead of login/bootstrap servers, weren't you? when you resolve endpoint addresses by dns, for what is dht? (and vice versa) sorry, totally confused. pp ----- Original Message ----- From: "David Barrett" To: "'Peter Pan'" ; "'Hannes Tschofenig'" Cc: Sent: Monday, August 20, 2007 3:46 PM Subject: RE: [P2PSIP] Auth/boot is weakest link > > -----Original Message----- > > From: Peter Pan > > Subject: Re: [P2PSIP] Auth/boot is weakest link > > > > do u mean that we should turn our heads away from dht technologies? > > No, whether or not to use a DHT is another discussion entirely. > > However, even with a DHT used for rendezvous purposes (which I believe is > the intent of P2PSIP), some other service (non-DHT?) must exist for > authentication and bootstrapping into the network. It looked like it was > the authentication/bootstrapping services that failed in the Skype case > (though now it's looking like a problem in the p2p layer), and thus I'm > curious what solutions are on the table for authentication and > bootstrapping. > > > > another question, can existing dns infrastructure carry millions or even > > billions of individual sip ua's without overhaul? > > I don't see why it couldn't, at least by the time there are truly millions > or billions of individual SIP UA's using it. Recall -- even Skype only has > 9M simultaneous, and that makes up nearly 100% of all internet-based VoIP. > It'll be a long, long time before P2PSIP has anything similar to those > numbers. > > -david > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Aug 20 20:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INHQI-0000yT-KH; Mon, 20 Aug 2007 20:16:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INHQG-0000sa-Qx for p2psip@ietf.org; Mon, 20 Aug 2007 20:16:40 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INHQF-0006x6-8T for p2psip@ietf.org; Mon, 20 Aug 2007 20:16:40 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 20 Aug 2007 17:16:36 -0700 From: "David Barrett" To: "'Peter Pan'" , "'Hannes Tschofenig'" Subject: RE: [P2PSIP] Auth/boot is weakest link Date: Mon, 20 Aug 2007 17:16:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <00fb01c7e386$e8aad0e0$030aa8c0@comcast.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfjhmc1maZ3rllIQb6hLgaFMGEAXAAAWFsg X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Message-Id: > -----Original Message----- > From: Peter Pan [mailto:huang-ming.pan@comcast.net] > Subject: Re: [P2PSIP] Auth/boot is weakest link > > i thought you were recommending dns for resolving addresses of endpoints > instead of login/bootstrap servers, weren't you? > > when you resolve endpoint addresses by dns, for what is dht? (and vice > versa) > > sorry, totally confused. You're right -- using dynDNS/mDNS you wouldn't need the DHT. I'm sorry, it was confusing for me to mention it, as that's not the angle I'm trying to investigate. (I was just holding it up as one solution to the authentication/bootstrapping problem in order to stimulate conversation on alternatives.) What I'm trying to ask is: If you *do* choose to use a DHT, what are the top proposals for how to solve the authentication and bootstrapping problems? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Aug 20 20:35:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INHiE-0006Em-67; Mon, 20 Aug 2007 20:35:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INHiC-0006EY-2J for p2psip@ietf.org; Mon, 20 Aug 2007 20:35:12 -0400 Received: from alnrmhc16.comcast.net ([204.127.225.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INHiB-0002dl-O4 for p2psip@ietf.org; Mon, 20 Aug 2007 20:35:11 -0400 Received: from home2000 (c-76-21-99-127.hsd1.ca.comcast.net[76.21.99.127]) by comcast.net (alnrmhc16) with SMTP id <20070821003506b1600s34ide>; Tue, 21 Aug 2007 00:35:11 +0000 Message-ID: <010b01c7e38b$a8d7c220$030aa8c0@comcast.net> From: "Peter Pan" To: "David Barrett" , "'Hannes Tschofenig'" Subject: Re: [P2PSIP] Auth/boot is weakest link Date: Mon, 20 Aug 2007 17:38:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Spam-Score: 2.2 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 imo, initial bootstrapping and certificate renewal need centralized ca or login servers, which needs dns. other than that, dht seems fit. pp ----- Original Message ----- From: "David Barrett" To: "'Peter Pan'" ; "'Hannes Tschofenig'" Cc: Sent: Monday, August 20, 2007 5:16 PM Subject: RE: [P2PSIP] Auth/boot is weakest link > > -----Original Message----- > > From: Peter Pan [mailto:huang-ming.pan@comcast.net] > > Subject: Re: [P2PSIP] Auth/boot is weakest link > > > > i thought you were recommending dns for resolving addresses of endpoints > > instead of login/bootstrap servers, weren't you? > > > > when you resolve endpoint addresses by dns, for what is dht? (and vice > > versa) > > > > sorry, totally confused. > > You're right -- using dynDNS/mDNS you wouldn't need the DHT. I'm sorry, it > was confusing for me to mention it, as that's not the angle I'm trying to > investigate. (I was just holding it up as one solution to the > authentication/bootstrapping problem in order to stimulate conversation on > alternatives.) > > What I'm trying to ask is: > > If you *do* choose to use a DHT, what are the top proposals for how to solve > the authentication and bootstrapping problems? > > -david > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Aug 25 09:49:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOw0Z-0004sh-Eh; Sat, 25 Aug 2007 09:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOw0W-0004sG-SO for p2psip@ietf.org; Sat, 25 Aug 2007 09:48:57 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOw0V-0005e7-Kg for p2psip@ietf.org; Sat, 25 Aug 2007 09:48:56 -0400 Received: from dialin-163-179.tor.primus.ca ([216.254.163.179]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IOw0H-0002Gd-1p; Sat, 25 Aug 2007 09:48:42 -0400 In-Reply-To: <1187480490.2EDA74A9@fd7.dngr.org> References: <1187479770.27100397@fd5.dngr.org> <1187480490.2EDA74A9@fd7.dngr.org> 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 Subject: Re: [P2PSIP] Auth/boot is weakest link Date: Fri, 24 Aug 2007 16:29:08 -0400 To: David Barrett X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - dialin-163-179.tor.primus.ca [216.254.163.179] X-Spam-Score: 1.8 (+) 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 David: draft-matthews-p2psip-bootstrap-mechanisms-00 is one attempt to describe how the bootstrap process might work in P2PSIP. It is a bit dated now (because it used SIP as a signaling protocol for setting up control connections, which the authors no longer think is the correct approach), but the basic ideas are still valid. Note however, that we did not address the security issues. - Philip On 18-Aug-07, at 19:41 , David Barrett wrote: > Any thoughts on the latest Skype debacle? > > Generally Skype is held up as justification of the power of p2p > voip. However, as clearly evidenced in the past week, a system is > only as decentralized as its most centralized link: in this case, > bootstrapping and authentication. > > What's the latest thinking about how p2psip would fare better? > > While no official position has been taken on the issue, it's been > argued that a combination of DNS/mDNS makes a good candidate. > (Though technically centralized, it's highly redundant and > distributed, as well as decentralized in a legal sense -- especialy > when compared to Skype!) > > What other options are on the table for providing authentication > and bootstrapping in a way that's superior to Skype? > > -david > > _______________________________________________ > 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 Mon Aug 27 13:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPiTs-0002fP-V5; Mon, 27 Aug 2007 13:34:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPiTr-0002bj-If for p2psip@ietf.org; Mon, 27 Aug 2007 13:34:27 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPiTq-0007gn-D5 for p2psip@ietf.org; Mon, 27 Aug 2007 13:34:27 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNG009WG0TDUC@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 27 Aug 2007 10:34:26 -0700 (PDT) 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 2.14 (built Aug 8 2006)) with ESMTPA id <0JNG00IGP0T8MY@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 27 Aug 2007 10:34:25 -0700 (PDT) Date: Mon, 27 Aug 2007 12:34:46 -0500 From: Spencer Dawkins To: P2PSIP Mailing List Message-id: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [P2PSIP] Use Cases -> Deployment Scenarios? 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 In conversations with David and Bruce on a revision of the Use Cases draft, it's becoming fairly obvious that what we're talking about isn't use cases at all... http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html A quick look at http://en.wikipedia.org/wiki/Use_case confirms my memory that a "use case" focuses on the interaction between a user and a system, where the system is modeled as a "black box" (no internal interfaces matter). This isn't what the current draft does. I'm suggesting something like "deployment scenarios" Doees this work for people? Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Aug 27 13:51:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPikV-0005rP-Ox; Mon, 27 Aug 2007 13:51:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPikU-0005rH-A8 for p2psip@ietf.org; Mon, 27 Aug 2007 13:51:38 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPikT-0008FH-3N for p2psip@ietf.org; Mon, 27 Aug 2007 13:51:38 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IPikF-0005pt-2C; Mon, 27 Aug 2007 13:51:23 -0400 In-Reply-To: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com> References: <063c01c7e8d0$90c8f880$6801a8c0@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: <83E80E54-0C7B-444D-9EF3-DAAEEABE976E@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? Date: Mon, 27 Aug 2007 13:51:34 -0400 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 that "use-case" doesn't seem to be the right term. For some time, I have been using the term "usage scenario". Might this be even better than "deployment scenario"? - Philip On 27-Aug-07, at 13:34 , Spencer Dawkins wrote: > In conversations with David and Bruce on a revision of the Use > Cases draft, it's becoming fairly obvious that what we're talking > about isn't use cases at all... > > http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html > > A quick look at http://en.wikipedia.org/wiki/Use_case confirms my > memory that a "use case" focuses on the interaction between a user > and a system, where the system is modeled as a "black box" (no > internal interfaces matter). > > This isn't what the current draft does. I'm suggesting something > like "deployment scenarios" > > Doees this work for people? > > 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 Mon Aug 27 14:38:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPjU2-0007kZ-Tj; Mon, 27 Aug 2007 14:38:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPjU0-0007kK-Um for p2psip@ietf.org; Mon, 27 Aug 2007 14:38:40 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPjTz-0001B9-OM for p2psip@ietf.org; Mon, 27 Aug 2007 14:38:40 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNG009LM3SFUC@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 27 Aug 2007 11:38:39 -0700 (PDT) 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 2.14 (built Aug 8 2006)) with ESMTPA id <0JNG007M13SDT6@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 27 Aug 2007 11:38:39 -0700 (PDT) Date: Mon, 27 Aug 2007 13:39:02 -0500 From: Spencer Dawkins Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? To: P2PSIP Mailing List Message-id: <067801c7e8d9$8a6ec150$6801a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 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: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com> <83E80E54-0C7B-444D-9EF3-DAAEEABE976E@magma.ca> 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 was probably mis-quoting from memory a coversation with you - "usage scenario" would work for me, too (even better than "use case", which I think is the target I'm shooting at). Thanks, Spencer >I agree that "use-case" doesn't seem to be the right term. > > For some time, I have been using the term "usage scenario". Might this be > even better than "deployment scenario"? > > - Philip > > On 27-Aug-07, at 13:34 , Spencer Dawkins wrote: > >> In conversations with David and Bruce on a revision of the Use Cases >> draft, it's becoming fairly obvious that what we're talking about isn't >> use cases at all... >> >> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html >> >> A quick look at http://en.wikipedia.org/wiki/Use_case confirms my memory >> that a "use case" focuses on the interaction between a user and a >> system, where the system is modeled as a "black box" (no internal >> interfaces matter). >> >> This isn't what the current draft does. I'm suggesting something like >> "deployment scenarios" >> >> Doees this work for people? >> >> 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 Mon Aug 27 17:15: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 1IPlvW-0000AJ-MP; Mon, 27 Aug 2007 17:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPlvV-0008GQ-A4 for p2psip@ietf.org; Mon, 27 Aug 2007 17:15:13 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPlvS-00066I-D2 for p2psip@ietf.org; Mon, 27 Aug 2007 17:15:11 -0400 Received: by nf-out-0910.google.com with SMTP id c10so1233706nfd for ; Mon, 27 Aug 2007 14:15:09 -0700 (PDT) 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:references; b=j+J5RkOJXc5VGdqbIgzf4MJLsaEelf7PvvSVb0H53Crdv2dkbtsrOzefd9AEXtG1w9CU51q05gDvZvBLDZJLDXBYFEVGa2KKQQ/O7O0Kr4R5o6UoiDM+6jvFXLNQvXiNqV7VA/VOVXhu2u/XarGv7h3SGEy+xnk2etH/UKDpz0E= 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=f4Dr49mYHbu+YLoBnjE+JmbOAgh9VXahQzTICts6QrWQmVGeDSTj+PFiMsgQmUF4qommB0ZquocQ9saBSkSPy3lZbDUMdOlfdAIQ0po0/gRV6SdGoJz5gEPFlx+4n0wqbu3Q+yzW17DZ8lK4wcHdtlXJynnJKmw2lcr2BRwWP80= Received: by 10.78.149.15 with SMTP id w15mr4306677hud.1188249309014; Mon, 27 Aug 2007 14:15:09 -0700 (PDT) Received: by 10.78.56.8 with HTTP; Mon, 27 Aug 2007 14:15:03 -0700 (PDT) Message-ID: <7b683f3f0708271415g19f53c1as7a959c2c4283a715@mail.gmail.com> Date: Mon, 27 Aug 2007 17:15:03 -0400 From: "Eunsoo Shim" To: "Spencer Dawkins" Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? In-Reply-To: <067801c7e8d9$8a6ec150$6801a8c0@china.huawei.com> MIME-Version: 1.0 References: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com> <83E80E54-0C7B-444D-9EF3-DAAEEABE976E@magma.ca> <067801c7e8d9$8a6ec150$6801a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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: , Content-Type: multipart/mixed; boundary="===============0313479019==" Errors-To: p2psip-bounces@ietf.org --===============0313479019== Content-Type: multipart/alternative; boundary="----=_Part_75772_3801641.1188249303900" ------=_Part_75772_3801641.1188249303900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Either usage scenario or deployment scenario is fine with me. Thanks. Eunsoo On 8/27/07, Spencer Dawkins wrote: > > Hi, Philip, > > I was probably mis-quoting from memory a coversation with you - "usage > scenario" would work for me, too (even better than "use case", which I > think > is the target I'm shooting at). > > Thanks, > > Spencer > > > >I agree that "use-case" doesn't seem to be the right term. > > > > For some time, I have been using the term "usage scenario". Might this > be > > even better than "deployment scenario"? > > > > - Philip > > > > On 27-Aug-07, at 13:34 , Spencer Dawkins wrote: > > > >> In conversations with David and Bruce on a revision of the Use Cases > >> draft, it's becoming fairly obvious that what we're talking about > isn't > >> use cases at all... > >> > >> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html > >> > >> A quick look at http://en.wikipedia.org/wiki/Use_case confirms > my memory > >> that a "use case" focuses on the interaction between a user and a > >> system, where the system is modeled as a "black box" (no internal > >> interfaces matter). > >> > >> This isn't what the current draft does. I'm suggesting something like > >> "deployment scenarios" > >> > >> Doees this work for people? > >> > >> 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 > ------=_Part_75772_3801641.1188249303900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Either usage scenario or deployment scenario is fine with me.
Thanks.

Eunsoo

On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote:
Hi, Philip,

I was probably mis-quoting from memory a coversation with you - "usage
scenario" would work for me, too (even better than "use case", which I think
is the target I'm shooting at).

Thanks,

Spencer


>I agree that "use-case" doesn't seem to be the right term.
>
> For some time, I have been using the term "usage scenario". Might  this be
> even better than "deployment scenario"?
>
> - Philip
>
> On 27-Aug-07, at 13:34 , Spencer Dawkins wrote:
>
>> In conversations with David and Bruce on a revision of the Use  Cases
>> draft, it's becoming fairly obvious that what we're talking  about isn't
>> use cases at all...
>>
>> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html
>>
>> A quick look at http://en.wikipedia.org/wiki/Use_case confirms my  memory
>> that a "use case" focuses on the interaction between a user  and a
>> system, where the system is modeled as a "black box" (no  internal
>> interfaces matter).
>>
>> This isn't what the current draft does. I'm suggesting something  like
>> "deployment scenarios"
>>
>> Doees this work for people?
>>
>> 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

------=_Part_75772_3801641.1188249303900-- --===============0313479019== 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 --===============0313479019==-- From p2psip-bounces@ietf.org Mon Aug 27 22:33:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPqtT-0003nd-OZ; Mon, 27 Aug 2007 22:33:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPqtS-0003nX-6v for p2psip@ietf.org; Mon, 27 Aug 2007 22:33:26 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPqtR-0000rG-9d for p2psip@ietf.org; Mon, 27 Aug 2007 22:33:26 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 27 Aug 2007 19:33:09 PDT 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 l7S2X79T004528; Mon, 27 Aug 2007 19:33:08 -0700 (PDT) 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 l7S2X6RC018730; Mon, 27 Aug 2007 19:33:06 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 19:33:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Use Cases -> Deployment Scenarios? Date: Mon, 27 Aug 2007 19:31:03 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE007@namail5.corp.adobe.com> In-Reply-To: <7b683f3f0708271415g19f53c1as7a959c2c4283a715@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Use Cases -> Deployment Scenarios? Thread-Index: Acfo74xASYenDg+QQrWVuh3pv3hLwwAKaX3Q References: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com><83E80E54-0C7B-444D-9EF3-DAAEEABE976E@magma.ca><067801c7e8d9$8a6ec150$6801a8c0@china.huawei.com> <7b683f3f0708271415g19f53c1as7a959c2c4283a715@mail.gmail.com> From: "Henry Sinnreich" To: "Eunsoo Shim" , "Spencer Dawkins" X-OriginalArrivalTime: 28 Aug 2007 02:33:06.0706 (UTC) FILETIME=[C41E5720:01C7E91B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 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: , Content-Type: multipart/mixed; boundary="===============1060044941==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1060044941== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E91B.C38EFD5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E91B.C38EFD5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A usage scenario is what the user does. A deployment scenario is what the service provider spends money on in the belief to know what the user wants or to control the user no matter what they want :-) * Now seriously, they are different and a definition of the meaning in the context of the I-D would be useful. =20 Henry ________________________________ From: Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: Monday, August 27, 2007 4:15 PM To: Spencer Dawkins Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? =20 Either usage scenario or deployment scenario is fine with me. Thanks. Eunsoo On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org > wrote: Hi, Philip, I was probably mis-quoting from memory a coversation with you - "usage=20 scenario" would work for me, too (even better than "use case", which I think is the target I'm shooting at). Thanks, Spencer >I agree that "use-case" doesn't seem to be the right term.=20 > > For some time, I have been using the term "usage scenario". Might this be > even better than "deployment scenario"? > > - Philip > > On 27-Aug-07, at 13:34 , Spencer Dawkins wrote:=20 > >> In conversations with David and Bruce on a revision of the Use Cases >> draft, it's becoming fairly obvious that what we're talking about isn't >> use cases at all... >> >> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html >> >> A quick look at http://en.wikipedia.org/wiki/Use_case confirms my memory >> that a "use case" focuses on the interaction between a user and a >> system, where the system is modeled as a "black box" (no internal=20 >> interfaces matter). >> >> This isn't what the current draft does. I'm suggesting something like >> "deployment scenarios" >> >> Doees this work for people?=20 >> >> Thanks, >> >> Spencer >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________=20 P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------_=_NextPart_001_01C7E91B.C38EFD5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A usage scenario is what the user = does.

A deployment scenario is what the = service provider spends money on in the belief to know what the user wants or to control the user no matter what they want J

 

Now seriously, they are different = and a definition of the meaning in the context of the I-D would be = useful.

 

Henry

From: = Eunsoo Shim [mailto:eunsooshim@gmail.com] =
Sent: Monday, August 27, = 2007 4:15 PM
To: Spencer Dawkins
Cc: P2PSIP Mailing = List
Subject: Re: [P2PSIP] Use = Cases -> Deployment Scenarios?

 

Either usage = scenario or deployment scenario is fine with me.
Thanks.

Eunsoo

On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote:

Hi, Philip,

I was probably mis-quoting from memory a coversation with you - = "usage
scenario" would work for me, too (even better than "use = case", which I think
is the target I'm shooting = at).

Thanks,

Spencer


>I agree that "use-case" doesn't seem to be the right term. =
>
> For some time, I have been using the term "usage = scenario". Might  this be
> even better than "deployment scenario"?
>
> - Philip
>
> On 27-Aug-07, at 13:34 , Spencer Dawkins wrote:
>
>> In conversations with David and Bruce on a revision of the Use  Cases
>> draft, it's becoming fairly obvious that what we're talking  about isn't
>> use cases at all...
>>
>> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html
= >>
>> A quick look at http://en.wikipedia.org/wi= ki/Use_case confirms my  memory
>> that a "use case" focuses on the interaction between = a user  and a
>> system, where the system is modeled as a "black box" (no  internal
>> interfaces matter).
>>
>> This isn't what the current draft does. I'm suggesting something  like
>> "deployment scenarios"
>>
>> Doees this work for people?
>>
>> 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

 

------_=_NextPart_001_01C7E91B.C38EFD5F-- --===============1060044941== 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 --===============1060044941==-- From p2psip-bounces@ietf.org Tue Aug 28 00:24:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPscT-0003op-9c; Tue, 28 Aug 2007 00:24:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPscS-0003oj-62 for p2psip@ietf.org; Tue, 28 Aug 2007 00:24:00 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPscQ-0008UO-Fm for p2psip@ietf.org; Tue, 28 Aug 2007 00:24:00 -0400 Received: by nf-out-0910.google.com with SMTP id c10so1309921nfd for ; Mon, 27 Aug 2007 21:23:57 -0700 (PDT) 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:references; b=haWE0Hc5CaAmdMfimzBUQo/8bpz2xZeqpNaziOWXemW69joxdhWNIJ+ksEp4rLvUHzWvjl/ntdok33xoWMiVIo/Ucn7DF2Mqb5FzuzNhqzFFAyeFm95ig8CSurgTXmTOIOEb3HMoKQpMMntsaFlKlQm8UFQJNl4Z+BOHHRHybXQ= 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=Qmr1KzxDfgafUYEf1XhmAT7eny5+S+dBnW9JdVG6gccIIsPm6n7VE1F35jcXNKXnC44Y5uJft0POOzcIMjKKtoti71BAMx89T1FksXccSUzCOjCRPoyW74kqJKKKTWGT0p6TAykf/8SmZMIKU+ne5+chAuFkcsAd9ARJJM0eNDE= Received: by 10.78.183.8 with SMTP id g8mr4484235huf.1188275036906; Mon, 27 Aug 2007 21:23:56 -0700 (PDT) Received: by 10.78.56.8 with HTTP; Mon, 27 Aug 2007 21:23:56 -0700 (PDT) Message-ID: <7b683f3f0708272123y44f6e0e7j7ca7e66b22810ee3@mail.gmail.com> Date: Tue, 28 Aug 2007 00:23:56 -0400 From: "Eunsoo Shim" To: "Henry Sinnreich" Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE007@namail5.corp.adobe.com> MIME-Version: 1.0 References: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com> <83E80E54-0C7B-444D-9EF3-DAAEEABE976E@magma.ca> <067801c7e8d9$8a6ec150$6801a8c0@china.huawei.com> <7b683f3f0708271415g19f53c1as7a959c2c4283a715@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE007@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 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: , Content-Type: multipart/mixed; boundary="===============2007559443==" Errors-To: p2psip-bounces@ietf.org --===============2007559443== Content-Type: multipart/alternative; boundary="----=_Part_77847_9106510.1188275036848" ------=_Part_77847_9106510.1188275036848 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Oops. This naming discussion is getting serious. What I understand is that the I-D is about various communication applications/scenarios for which P2P SIP can be useful. If none of 'use cases', 'usage scenarios', and 'deployment scenarios' is a proper name for the I-D, I (or we) need help. Is 'application scenarios' OK? Or any suggestion? Thanks. Charlie On 8/27/07, Henry Sinnreich wrote: > > A usage scenario is what the user does. > > A deployment scenario is what the service provider spends money on in the > belief to know what the user wants or to control the user no matter what > they want J > > > > Now seriously, they are different and a definition of the meaning in the > context of the I-D would be useful. > > > > Henry > ------------------------------ > > *From:* Eunsoo Shim [mailto:eunsooshim@gmail.com] > *Sent:* Monday, August 27, 2007 4:15 PM > *To:* Spencer Dawkins > *Cc:* P2PSIP Mailing List > *Subject:* Re: [P2PSIP] Use Cases -> Deployment Scenarios? > > > > Either usage scenario or deployment scenario is fine with me. > Thanks. > > Eunsoo > > On 8/27/07, *Spencer Dawkins* < spencer@mcsr-labs.org> wrote: > > Hi, Philip, > > I was probably mis-quoting from memory a coversation with you - "usage > scenario" would work for me, too (even better than "use case", which I > think > is the target I'm shooting at). > > Thanks, > > Spencer > > > >I agree that "use-case" doesn't seem to be the right term. > > > > For some time, I have been using the term "usage scenario". Might this > be > > even better than "deployment scenario"? > > > > - Philip > > > > On 27-Aug-07, at 13:34 , Spencer Dawkins wrote: > > > >> In conversations with David and Bruce on a revision of the Use Cases > >> draft, it's becoming fairly obvious that what we're talking about > isn't > >> use cases at all... > >> > >> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html > >> > >> A quick look at http://en.wikipedia.org/wiki/Use_case confirms > my memory > >> that a "use case" focuses on the interaction between a user and a > >> system, where the system is modeled as a "black box" (no internal > >> interfaces matter). > >> > >> This isn't what the current draft does. I'm suggesting something like > >> "deployment scenarios" > >> > >> Doees this work for people? > >> > >> 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 > > > ------=_Part_77847_9106510.1188275036848 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Oops. This naming discussion is getting serious.
What I understand is that the I-D is about various communication applications/scenarios for which P2P SIP can be useful.
If none of 'use cases', 'usage scenarios', and 'deployment scenarios' is a proper name for the I-D, I (or we) need help.
Is 'application scenarios' OK? Or any suggestion?
Thanks.

Charlie

On 8/27/07, Henry Sinnreich < hsinnrei@adobe.com> wrote:

A usage scenario is what the user does.

A deployment scenario is what the service provider spends money on in the belief to know what the user wants or to control the user no matter what they want J

 

Now seriously, they are different and a definition of the meaning in the context of the I-D would be useful.

 

Henry

From: Eunsoo Shim [mailto: eunsooshim@gmail.com]
Sent: Monday, August 27, 2007 4:15 PM
To: Spencer Dawkins
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios?

 

Either usage scenario or deployment scenario is fine with me.
Thanks.

Eunsoo

On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote:

Hi, Philip,

I was probably mis-quoting from memory a coversation with you - "usage
scenario" would work for me, too (even better than "use case", which I think
is the target I'm shooting at).

Thanks,

Spencer


>I agree that "use-case" doesn't seem to be the right term.
>
> For some time, I have been using the term "usage scenario". Might  this be
> even better than "deployment scenario"?
>
> - Philip
>
> On 27-Aug-07, at 13:34 , Spencer Dawkins wrote:
>
>> In conversations with David and Bruce on a revision of the Use  Cases
>> draft, it's becoming fairly obvious that what we're talking  about isn't
>> use cases at all...
>>
>> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html
>>
>> A quick look at http://en.wikipedia.org/wiki/Use_case confirms my  memory
>> that a "use case" focuses on the interaction between a user  and a
>> system, where the system is modeled as a "black box" (no  internal
>> interfaces matter).
>>
>> This isn't what the current draft does. I'm suggesting something  like
>> "deployment scenarios"
>>
>> Doees this work for people?
>>
>> 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

 


------=_Part_77847_9106510.1188275036848-- --===============2007559443== 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 --===============2007559443==-- From p2psip-bounces@ietf.org Tue Aug 28 10:59:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ2Xo-0004qf-32; Tue, 28 Aug 2007 10:59:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ2Xn-0004qZ-Ag for p2psip@ietf.org; Tue, 28 Aug 2007 10:59:51 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ2Xl-0004vq-Lc for p2psip@ietf.org; Tue, 28 Aug 2007 10:59:51 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 28 Aug 2007 07:59:39 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7SEw3IQ014644; Tue, 28 Aug 2007 07:58:03 -0700 (PDT) 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 l7SExVRG009669; Tue, 28 Aug 2007 07:59:35 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 07:59:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Use Cases -> Deployment Scenarios? Date: Tue, 28 Aug 2007 07:59:10 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE00C@namail5.corp.adobe.com> In-Reply-To: <7b683f3f0708272123y44f6e0e7j7ca7e66b22810ee3@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Use Cases -> Deployment Scenarios? Thread-Index: AcfpK0IgMk0J0DIFT1GJKviYG5IJUgAWJGCw References: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com> <83E80E54-0C7B-444D-9EF3-DAAEEABE976E@magma.ca> <067801c7e8d9$8a6ec150$6801a8c0@china.huawei.com> <7b683f3f0708271415g19f53c1as7a959c2c4283a715@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE007@namail5.corp.adobe.com> <7b683f3f0708272123y44f6e0e7j7ca7e66b22810ee3@mail.gmail.com> From: "Henry Sinnreich" To: "Eunsoo Shim" X-OriginalArrivalTime: 28 Aug 2007 14:59:31.0673 (UTC) FILETIME=[0A09FC90:01C7E984] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0 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: , Content-Type: multipart/mixed; boundary="===============1512491096==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1512491096== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E984.08C3738B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E984.08C3738B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Application scenarios look good to me. It avoids defining the other terms. =20 Henry =20 ________________________________ From: Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: Monday, August 27, 2007 11:24 PM To: Henry Sinnreich Cc: Spencer Dawkins; P2PSIP Mailing List Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? =20 Oops. This naming discussion is getting serious. What I understand is that the I-D is about various communication applications/scenarios for which P2P SIP can be useful. If none of 'use cases', 'usage scenarios', and 'deployment scenarios' is a proper name for the I-D, I (or we) need help.=20 Is 'application scenarios' OK? Or any suggestion? Thanks. Charlie On 8/27/07, Henry Sinnreich < hsinnrei@adobe.com > wrote: A usage scenario is what the user does. A deployment scenario is what the service provider spends money on in the belief to know what the user wants or to control the user no matter what they want :-) =20 Now seriously, they are different and a definition of the meaning in the context of the I-D would be useful. =20 Henry ________________________________ From: Eunsoo Shim [mailto: eunsooshim@gmail.com]=20 Sent: Monday, August 27, 2007 4:15 PM To: Spencer Dawkins Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? =20 Either usage scenario or deployment scenario is fine with me. Thanks. Eunsoo On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org > wrote: Hi, Philip, I was probably mis-quoting from memory a coversation with you - "usage=20 scenario" would work for me, too (even better than "use case", which I think is the target I'm shooting at). Thanks, Spencer >I agree that "use-case" doesn't seem to be the right term.=20 > > For some time, I have been using the term "usage scenario". Might this be > even better than "deployment scenario"? > > - Philip > > On 27-Aug-07, at 13:34 , Spencer Dawkins wrote:=20 > >> In conversations with David and Bruce on a revision of the Use Cases >> draft, it's becoming fairly obvious that what we're talking about isn't >> use cases at all... >> >> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html=20 >> >> A quick look at http://en.wikipedia.org/wiki/Use_case confirms my memory >> that a "use case" focuses on the interaction between a user and a >> system, where the system is modeled as a "black box" (no internal=20 >> interfaces matter). >> >> This isn't what the current draft does. I'm suggesting something like >> "deployment scenarios" >> >> Doees this work for people?=20 >> >> Thanks, >> >> Spencer >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________=20 P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 =20 ------_=_NextPart_001_01C7E984.08C3738B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Application scenarios look good to = me. It avoids defining the other terms.

 

Henry

 

From: = Eunsoo Shim [mailto:eunsooshim@gmail.com] =
Sent: Monday, August 27, = 2007 11:24 PM
To: Henry Sinnreich
Cc: Spencer Dawkins; P2PSIP Mailing = List
Subject: Re: [P2PSIP] Use = Cases -> Deployment Scenarios?

 

Oops. This = naming discussion is getting serious.
What I understand is that the I-D is about various communication applications/scenarios for which P2P SIP can be useful.
If none of 'use cases', 'usage scenarios', and 'deployment scenarios' is = a proper name for the I-D, I (or we) need help.
Is 'application scenarios' OK? Or any suggestion?
Thanks.

Charlie

On 8/27/07, Henry Sinnreich < hsinnrei@adobe.com> wrote:

A usage scenario is what the user = does.

A deployment scenario is what the service provider = spends money on in the belief to know what the user wants or to control the = user no matter what they want J

 

Now seriously, they are different and a definition of = the meaning in the context of the I-D would be = useful.

 

Henry

From: Eunsoo Shim [mailto: eunsooshim@gmail.com]
Sent: Monday, August 27, = 2007 4:15 PM
To: Spencer Dawkins
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Use = Cases -> Deployment Scenarios?

 

Either usage scenario or deployment scenario = is fine with me.
Thanks.

Eunsoo

On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote:

Hi, Philip,

I was probably mis-quoting from memory a coversation with you - = "usage
scenario" would work for me, too (even better than "use = case", which I think
is the target I'm shooting = at).

Thanks,

Spencer


>I agree that "use-case" doesn't seem to be the right term. =
>
> For some time, I have been using the term "usage = scenario". Might  this be
> even better than "deployment scenario"?
>
> - Philip
>
> On 27-Aug-07, at 13:34 , Spencer = Dawkins wrote:
>
>> In conversations with David and Bruce on a revision of the Use  Cases
>> draft, it's becoming fairly obvious that what we're talking  about isn't
>> use cases at all...
>>
>> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecase= s-00.html
>>
>> A quick look at http://en.wikipedia.org/wiki/Use_case confirms my  memory
>> that a "use case" focuses on the interaction between = a user  and a
>> system, where the system is modeled as a "black box" (no  internal
>> interfaces matter).
>>
>> This isn't what the current draft does. I'm suggesting something  like
>> "deployment scenarios"
>>
>> Doees this work for people?
>>
>> 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<= /o:p>

 

 

------_=_NextPart_001_01C7E984.08C3738B-- --===============1512491096== 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 --===============1512491096==-- From p2psip-bounces@ietf.org Tue Aug 28 11:19:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ2r8-0007n4-7U; Tue, 28 Aug 2007 11:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ2r7-0007mv-Mj for p2psip@ietf.org; Tue, 28 Aug 2007 11:19:49 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ2r6-0005XF-3x for p2psip@ietf.org; Tue, 28 Aug 2007 11:19:49 -0400 Received: by nf-out-0910.google.com with SMTP id c10so1439974nfd for ; Tue, 28 Aug 2007 08:19:47 -0700 (PDT) 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:references; b=XiNQLHzCoFiFSXPKy37JkCuGe2nv2LXtAHy6KD1NXjriY26P6rqDYS79kgEi0OSpMsfp+hCiYklcIBjUTQCWdGkYVbvuqX8NLHY/UbnIwgkITlAaKIY5jrYUby9GA2JYUBRywv8ACDH5iIK16bLmWJzBE0S6hs2EL3TfajNB/OY= 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=oyI/zoEPvVCT/+Ojjic++wv+aCsa6Q25xUij/vqpaKVZGA8R1zHf3XD8ldDZ6KdOqXT7PnUp1X+8pR/HGLRFf+uj+e3qAX1Dwmk8opRK5bnwNsjKWJsmRfxk9HwJStD2dgE0mwNGHb0P3E6Yc/2KUu6o00/Cob0A8wmXfyYxADY= Received: by 10.78.186.9 with SMTP id j9mr4956591huf.1188314381710; Tue, 28 Aug 2007 08:19:41 -0700 (PDT) Received: by 10.78.56.8 with HTTP; Tue, 28 Aug 2007 08:19:41 -0700 (PDT) Message-ID: <7b683f3f0708280819xe9e188t3f58e305edfdd669@mail.gmail.com> Date: Tue, 28 Aug 2007 11:19:41 -0400 From: "Eunsoo Shim" To: "Henry Sinnreich" Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE00C@namail5.corp.adobe.com> MIME-Version: 1.0 References: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com> <83E80E54-0C7B-444D-9EF3-DAAEEABE976E@magma.ca> <067801c7e8d9$8a6ec150$6801a8c0@china.huawei.com> <7b683f3f0708271415g19f53c1as7a959c2c4283a715@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE007@namail5.corp.adobe.com> <7b683f3f0708272123y44f6e0e7j7ca7e66b22810ee3@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE00C@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 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: , Content-Type: multipart/mixed; boundary="===============0903252307==" Errors-To: p2psip-bounces@ietf.org --===============0903252307== Content-Type: multipart/alternative; boundary="----=_Part_81587_273440.1188314381609" ------=_Part_81587_273440.1188314381609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Henry, Thanks a lot. Eunsoo On 8/28/07, Henry Sinnreich wrote: > > Application scenarios look good to me. It avoids defining the other > terms. > > > > Henry > > > ------------------------------ > > *From:* Eunsoo Shim [mailto:eunsooshim@gmail.com] > *Sent:* Monday, August 27, 2007 11:24 PM > *To:* Henry Sinnreich > *Cc:* Spencer Dawkins; P2PSIP Mailing List > *Subject:* Re: [P2PSIP] Use Cases -> Deployment Scenarios? > > > > Oops. This naming discussion is getting serious. > What I understand is that the I-D is about various communication > applications/scenarios for which P2P SIP can be useful. > If none of 'use cases', 'usage scenarios', and 'deployment scenarios' is a > proper name for the I-D, I (or we) need help. > Is 'application scenarios' OK? Or any suggestion? > Thanks. > > Charlie > > On 8/27/07, *Henry Sinnreich* < hsinnrei@adobe.com> wrote: > > A usage scenario is what the user does. > > A deployment scenario is what the service provider spends money on in the > belief to know what the user wants or to control the user no matter what > they want J > > > > Now seriously, they are different and a definition of the meaning in the > context of the I-D would be useful. > > > > Henry > ------------------------------ > > *From:* Eunsoo Shim [mailto: eunsooshim@gmail.com] > *Sent:* Monday, August 27, 2007 4:15 PM > *To:* Spencer Dawkins > *Cc:* P2PSIP Mailing List > *Subject:* Re: [P2PSIP] Use Cases -> Deployment Scenarios? > > > > Either usage scenario or deployment scenario is fine with me. > Thanks. > > Eunsoo > > On 8/27/07, *Spencer Dawkins* < spencer@mcsr-labs.org> wrote: > > Hi, Philip, > > I was probably mis-quoting from memory a coversation with you - "usage > scenario" would work for me, too (even better than "use case", which I > think > is the target I'm shooting at). > > Thanks, > > Spencer > > > >I agree that "use-case" doesn't seem to be the right term. > > > > For some time, I have been using the term "usage scenario". Might this > be > > even better than "deployment scenario"? > > > > - Philip > > > > On 27-Aug-07, at 13:34 , Spencer Dawkins wrote: > > > >> In conversations with David and Bruce on a revision of the Use Cases > >> draft, it's becoming fairly obvious that what we're talking about > isn't > >> use cases at all... > >> > >> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html > >> > >> A quick look at http://en.wikipedia.org/wiki/Use_case confirms > my memory > >> that a "use case" focuses on the interaction between a user and a > >> system, where the system is modeled as a "black box" (no internal > >> interfaces matter). > >> > >> This isn't what the current draft does. I'm suggesting something like > >> "deployment scenarios" > >> > >> Doees this work for people? > >> > >> 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 > > > > > ------=_Part_81587_273440.1188314381609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Henry,

Thanks a lot.

Eunsoo

On 8/28/07, Henry Sinnreich <hsinnrei@adobe.com> wrote:

Application scenarios look good to me. It avoids defining the other terms.

 

Henry

 

From: Eunsoo Shim [mailto: eunsooshim@gmail.com]
Sent: Monday, August 27, 2007 11:24 PM
To: Henry Sinnreich
Cc: Spencer Dawkins; P2PSIP Mailing List


Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios?

 

Oops. This naming discussion is getting serious.
What I understand is that the I-D is about various communication applications/scenarios for which P2P SIP can be useful.
If none of 'use cases', 'usage scenarios', and 'deployment scenarios' is a proper name for the I-D, I (or we) need help.
Is 'application scenarios' OK? Or any suggestion?
Thanks.

Charlie

On 8/27/07, Henry Sinnreich < hsinnrei@adobe.com> wrote:

A usage scenario is what the user does.

A deployment scenario is what the service provider spends money on in the belief to know what the user wants or to control the user no matter what they want J

 

Now seriously, they are different and a definition of the meaning in the context of the I-D would be useful.

 

Henry

From: Eunsoo Shim [mailto: eunsooshim@gmail.com]
Sent: Monday, August 27, 2007 4:15 PM
To: Spencer Dawkins
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios?

 

Either usage scenario or deployment scenario is fine with me.
Thanks.

Eunsoo

On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote:

Hi, Philip,

I was probably mis-quoting from memory a coversation with you - "usage
scenario" would work for me, too (even better than "use case", which I think
is the target I'm shooting at).

Thanks,

Spencer


>I agree that "use-case" doesn't seem to be the right term.
>
> For some time, I have been using the term "usage scenario". Might  this be
> even better than "deployment scenario"?
>
> - Philip
>
> On 27-Aug-07, at 13:34 , Spencer Dawkins wrote:
>
>> In conversations with David and Bruce on a revision of the Use  Cases
>> draft, it's becoming fairly obvious that what we're talking  about isn't
>> use cases at all...
>>
>> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html
>>
>> A quick look at http://en.wikipedia.org/wiki/Use_case confirms my  memory
>> that a "use case" focuses on the interaction between a user  and a
>> system, where the system is modeled as a "black box" (no  internal
>> interfaces matter).
>>
>> This isn't what the current draft does. I'm suggesting something  like
>> "deployment scenarios"
>>
>> Doees this work for people?
>>
>> 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

 

 


------=_Part_81587_273440.1188314381609-- --===============0903252307== 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 --===============0903252307==-- From p2psip-bounces@ietf.org Tue Aug 28 11:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ3EM-00046q-5l; Tue, 28 Aug 2007 11:43:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ3EK-00046g-H0 for p2psip@ietf.org; Tue, 28 Aug 2007 11:43:48 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ3EJ-0004JV-IP for p2psip@ietf.org; Tue, 28 Aug 2007 11:43:48 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNH00DKHQCYSL@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 28 Aug 2007 08:43:46 -0700 (PDT) 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 2.14 (built Aug 8 2006)) with ESMTPA id <0JNH00LAQQCQ0K@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 28 Aug 2007 08:43:46 -0700 (PDT) Date: Tue, 28 Aug 2007 10:44:03 -0500 From: Spencer Dawkins Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? To: Eunsoo Shim , Henry Sinnreich Message-id: <074e01c7e98a$42df0820$6801a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com> <83E80E54-0C7B-444D-9EF3-DAAEEABE976E@magma.ca> <067801c7e8d9$8a6ec150$6801a8c0@china.huawei.com> <7b683f3f0708271415g19f53c1as7a959c2c4283a715@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE007@namail5.corp.adobe.com> <7b683f3f0708272123y44f6e0e7j7ca7e66b22810ee3@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE00C@namail5.corp.adobe.com> <7b683f3f0708280819xe9e188t3f58e305edfdd669@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae 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: , Content-Type: multipart/mixed; boundary="===============0029932174==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0029932174== Content-type: multipart/alternative; boundary="Boundary_(ID_MlaVikId3wN471bMWseEIQ)" This is a multi-part message in MIME format. --Boundary_(ID_MlaVikId3wN471bMWseEIQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Any objections? If not, I can start changing text... Spencer ----- Original Message ----- From: Eunsoo Shim To: Henry Sinnreich Cc: Spencer Dawkins ; P2PSIP Mailing List Sent: Tuesday, August 28, 2007 10:19 AM Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? Hi, Henry, Thanks a lot. Eunsoo On 8/28/07, Henry Sinnreich wrote: Application scenarios look good to me. It avoids defining the other terms. Henry ---------------------------------------------------------------------------- From: Eunsoo Shim [mailto: eunsooshim@gmail.com] Sent: Monday, August 27, 2007 11:24 PM To: Henry Sinnreich Cc: Spencer Dawkins; P2PSIP Mailing List Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? Oops. This naming discussion is getting serious. What I understand is that the I-D is about various communication applications/scenarios for which P2P SIP can be useful. If none of 'use cases', 'usage scenarios', and 'deployment scenarios' is a proper name for the I-D, I (or we) need help. Is 'application scenarios' OK? Or any suggestion? Thanks. Charlie On 8/27/07, Henry Sinnreich < hsinnrei@adobe.com> wrote: A usage scenario is what the user does. A deployment scenario is what the service provider spends money on in the belief to know what the user wants or to control the user no matter what they want J Now seriously, they are different and a definition of the meaning in the context of the I-D would be useful. Henry ---------------------------------------------------------------------------- From: Eunsoo Shim [mailto: eunsooshim@gmail.com] Sent: Monday, August 27, 2007 4:15 PM To: Spencer Dawkins Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? Either usage scenario or deployment scenario is fine with me. Thanks. Eunsoo On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote: Hi, Philip, I was probably mis-quoting from memory a coversation with you - "usage scenario" would work for me, too (even better than "use case", which I think is the target I'm shooting at). Thanks, Spencer >I agree that "use-case" doesn't seem to be the right term. > > For some time, I have been using the term "usage scenario". Might this be > even better than "deployment scenario"? > > - Philip > > On 27-Aug-07, at 13:34 , Spencer Dawkins wrote: > >> In conversations with David and Bruce on a revision of the Use Cases >> draft, it's becoming fairly obvious that what we're talking about isn't >> use cases at all... >> >> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html >> >> A quick look at http://en.wikipedia.org/wiki/Use_case confirms my memory >> that a "use case" focuses on the interaction between a user and a >> system, where the system is modeled as a "black box" (no internal >> interfaces matter). >> >> This isn't what the current draft does. I'm suggesting something like >> "deployment scenarios" >> >> Doees this work for people? >> >> 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 --Boundary_(ID_MlaVikId3wN471bMWseEIQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Any objections?
 
If not, I can start changing text...
 
Spencer
----- Original Message -----
Sent: Tuesday, August 28, 2007 10:19 AM
Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios?

Hi, Henry,

Thanks a lot.

Eunsoo

On 8/28/07, Henry Sinnreich <hsinnrei@adobe.com> wrote:

Application scenarios look good to me. It avoids defining the other terms.

 

Henry

 

From: Eunsoo Shim [mailto: eunsooshim@gmail.com]
Sent: Monday, August 27, 2007 11:24 PM
To: Henry Sinnreich
Cc: Spencer Dawkins; P2PSIP Mailing List


Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios?

 

Oops. This naming discussion is getting serious.
What I understand is that the I-D is about various communication applications/scenarios for which P2P SIP can be useful.
If none of 'use cases', 'usage scenarios', and 'deployment scenarios' is a proper name for the I-D, I (or we) need help.
Is 'application scenarios' OK? Or any suggestion?
Thanks.

Charlie

On 8/27/07, Henry Sinnreich < hsinnrei@adobe.com> wrote:

A usage scenario is what the user does.

A deployment scenario is what the service provider spends money on in the belief to know what the user wants or to control the user no matter what they want J

 

Now seriously, they are different and a definition of the meaning in the context of the I-D would be useful.

 

Henry

From: Eunsoo Shim [mailto: eunsooshim@gmail.com]
Sent: Monday, August 27, 2007 4:15 PM
To: Spencer Dawkins
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios?

 

Either usage scenario or deployment scenario is fine with me.
Thanks.

Eunsoo

On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote:

Hi, Philip,

I was probably mis-quoting from memory a coversation with you - "usage
scenario" would work for me, too (even better than "use case", which I think
is the target I'm shooting at).

Thanks,

Spencer


>I agree that "use-case" doesn't seem to be the right term.
>
> For some time, I have been using the term "usage scenario". Might  this be
> even better than "deployment scenario"?
>
> - Philip
>
> On 27-Aug-07, at 13:34 , Spencer Dawkins wrote:
>
>> In conversations with David and Bruce on a revision of the Use  Cases
>> draft, it's becoming fairly obvious that what we're talking  about isn't
>> use cases at all...
>>
>> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html
>>
>> A quick look at http://en.wikipedia.org/wiki/Use_case confirms my  memory
>> that a "use case" focuses on the interaction between a user  and a
>> system, where the system is modeled as a "black box" (no  internal
>> interfaces matter).
>>
>> This isn't what the current draft does. I'm suggesting something  like
>> "deployment scenarios"
>>
>> Doees this work for people?
>>
>> 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

 

 


--Boundary_(ID_MlaVikId3wN471bMWseEIQ)-- --===============0029932174== 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 --===============0029932174==-- From p2psip-bounces@ietf.org Tue Aug 28 13:10:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ4a3-0006K9-Po; Tue, 28 Aug 2007 13:10:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ4a2-0006Ft-0T for p2psip@ietf.org; Tue, 28 Aug 2007 13:10:18 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ4a0-0000T5-F9 for p2psip@ietf.org; Tue, 28 Aug 2007 13:10:17 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IQ4Zv-0000Y9-2s; Tue, 28 Aug 2007 13:10:12 -0400 In-Reply-To: <074e01c7e98a$42df0820$6801a8c0@china.huawei.com> References: <063c01c7e8d0$90c8f880$6801a8c0@china.huawei.com> <83E80E54-0C7B-444D-9EF3-DAAEEABE976E@magma.ca> <067801c7e8d9$8a6ec150$6801a8c0@china.huawei.com> <7b683f3f0708271415g19f53c1as7a959c2c4283a715@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE007@namail5.corp.adobe.com> <7b683f3f0708272123y44f6e0e7j7ca7e66b22810ee3@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE00C@namail5.corp.adobe.com> <7b683f3f0708280819xe9e188t3f58e305edfdd669@mail.gmail.com> <074e01c7e98a$42df0820$6801a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: From: Philip Matthews Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? Date: Tue, 28 Aug 2007 13:10:08 -0400 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: Henry Sinnreich , 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: , Content-Type: multipart/mixed; boundary="===============1467240102==" Errors-To: p2psip-bounces@ietf.org --===============1467240102== Content-Type: multipart/alternative; boundary=Apple-Mail-4--439589080 --Apple-Mail-4--439589080 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Works for me. - Philip On 28-Aug-07, at 11:44 , Spencer Dawkins wrote: > Any objections? > > If not, I can start changing text... > > Spencer > ----- Original Message ----- > From: Eunsoo Shim > To: Henry Sinnreich > Cc: Spencer Dawkins ; P2PSIP Mailing List > Sent: Tuesday, August 28, 2007 10:19 AM > Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? > > Hi, Henry, > > Thanks a lot. > > Eunsoo > > On 8/28/07, Henry Sinnreich wrote: > Application scenarios look good to me. It avoids defining the other > terms. > > > Henry > > > From: Eunsoo Shim [mailto: eunsooshim@gmail.com] > Sent: Monday, August 27, 2007 11:24 PM > To: Henry Sinnreich > Cc: Spencer Dawkins; P2PSIP Mailing List > > Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? > > > > Oops. This naming discussion is getting serious. > What I understand is that the I-D is about various communication > applications/scenarios for which P2P SIP can be useful. > If none of 'use cases', 'usage scenarios', and 'deployment > scenarios' is a proper name for the I-D, I (or we) need help. > Is 'application scenarios' OK? Or any suggestion? > Thanks. > > Charlie > > On 8/27/07, Henry Sinnreich < hsinnrei@adobe.com> wrote: > > A usage scenario is what the user does. > > A deployment scenario is what the service provider spends money on > in the belief to know what the user wants or to control the user no > matter what they want J > > > Now seriously, they are different and a definition of the meaning > in the context of the I-D would be useful. > > > Henry > > From: Eunsoo Shim [mailto: eunsooshim@gmail.com] > Sent: Monday, August 27, 2007 4:15 PM > To: Spencer Dawkins > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Use Cases -> Deployment Scenarios? > > > Either usage scenario or deployment scenario is fine with me. > Thanks. > > Eunsoo > > On 8/27/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote: > > Hi, Philip, > > I was probably mis-quoting from memory a coversation with you - "usage > scenario" would work for me, too (even better than "use case", > which I think > is the target I'm shooting at). > > Thanks, > > Spencer > > > >I agree that "use-case" doesn't seem to be the right term. > > > > For some time, I have been using the term "usage scenario". > Might this be > > even better than "deployment scenario"? > > > > - Philip > > > > On 27-Aug-07, at 13:34 , Spencer Dawkins wrote: > > > >> In conversations with David and Bruce on a revision of the Use > Cases > >> draft, it's becoming fairly obvious that what we're talking > about isn't > >> use cases at all... > >> > >> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases-00.html > >> > >> A quick look at http://en.wikipedia.org/wiki/Use_case confirms > my memory > >> that a "use case" focuses on the interaction between a user and a > >> system, where the system is modeled as a "black box" (no internal > >> interfaces matter). > >> > >> This isn't what the current draft does. I'm suggesting > something like > >> "deployment scenarios" > >> > >> Doees this work for people? > >> > >> 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 > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip --Apple-Mail-4--439589080 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Works for me.
- = Philip
On 28-Aug-07, at 11:44 , Spencer Dawkins = wrote:

Any = objections?
=A0
If not, = I can start changing text...
=A0
Spencer
----- Original = Message -----
Sent: Tuesday, = August 28, 2007 10:19 AM
Subject: Re: [P2PSIP] Use Cases -> Deployment = Scenarios?

Hi, Henry,

Thanks a = lot.

Eunsoo

On 8/28/07, = Henry Sinnreich <hsinnrei@adobe.com> = wrote:
=

Application = scenarios look good to me. It avoids defining the other = terms.

=A0

Henry

=A0

From: = Eunsoo Shim [mailto: eunsooshim@gmail.com]
Sent: Monday, August 27, 2007 = 11:24 PM
To: Henry = Sinnreich
Cc: = Spencer Dawkins; P2PSIP Mailing List


Subject: Re: [P2PSIP] Use Cases -> Deployment = Scenarios?


=A0

Oops. This naming discussion is getting serious.
What I = understand is that the I-D is about various communication = applications/scenarios for which P2P SIP can be useful.
If none of = 'use cases', 'usage scenarios', and 'deployment scenarios' is a = proper name for the I-D, I (or we) need help.
Is 'application = scenarios' OK? Or any = suggestion?
Thanks.

Charlie

=

On 8/27/07, Henry Sinnreich < hsinnrei@adobe.com> = wrote:

=

A usage = scenario is what the user does.

A deployment scenario is what the = service provider spends money on in the belief to know what the user = wants or to control the user no matter what they want = J

=A0

Now seriously, they are different and a = definition of the meaning in the context of the I-D would be = useful.

=A0

Henry

From: = Eunsoo Shim [mailto: eunsooshim@gmail.com]
Sent: Monday, August 27, 2007 = 4:15 PM
To: Spencer = Dawkins
Cc: P2PSIP = Mailing List
Subject: Re: [P2PSIP] Use Cases -> Deployment = Scenarios?

=A0

Either usage scenario or deployment scenario is fine with = me.
Thanks.

Eunsoo

On = 8/27/07, Spencer = Dawkins < = spencer@mcsr-labs.org> wrote:

Hi, = Philip,

I was probably mis-quoting from memory a coversation = with you - "usage
scenario" would work for me, too (even better = than "use case", which I think
is the target I'm shooting = at).

Thanks,

Spencer


>I agree that = "use-case" doesn't seem to be the right term.
>
> For = some time, I have been using the term "usage scenario". Might=A0=A0thi= s be
> even better than "deployment scenario"?
>
> = - Philip
>
> On 27-Aug-07, at 13:34 , Spencer Dawkins = wrote:
>
>> In conversations with David and Bruce on = a revision of the Use=A0=A0Cases
>> draft, it's becoming = fairly obvious that what we're talking=A0=A0about isn't
>> = use cases at all...
>>
>> http://www.p2psip.org/drafts/draft-bryan-p2psip-usecases= -00.html
>>
>> A quick look at http://en.wikipedia.org/wiki/Use_case confirms = my=A0=A0memory
>> that a "use case" focuses on the = interaction between a user=A0=A0and a
>> system, where the = system is modeled as a "black box" (no=A0=A0internal
>> = interfaces matter).
>>
>> This isn't what the current = draft does. I'm suggesting something=A0=A0like
>> = "deployment scenarios"
>>
>> Doees this work for = people?
>>
>> 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=

=A0
=A0

P2PSIP mailing list
=

= --Apple-Mail-4--439589080-- --===============1467240102== 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 --===============1467240102==-- From p2psip-bounces@ietf.org Wed Aug 29 03:05:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQHcH-00071g-SE; Wed, 29 Aug 2007 03:05:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQHcG-0006xG-4i for p2psip@ietf.org; Wed, 29 Aug 2007 03:05:28 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQHcF-0007Ja-E3 for p2psip@ietf.org; Wed, 29 Aug 2007 03:05:28 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNI00HA5WZYXW@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 29 Aug 2007 15:04:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNI00CBWWZXCN@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 29 Aug 2007 15:04:46 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNI00EOSWZTZ3@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 29 Aug 2007 15:04:45 +0800 (CST) Date: Wed, 29 Aug 2007 15:04:41 +0800 From: JiangXingFeng To: 'P2PSIP Mailing List' Message-id: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfqCt7M7MBEOvWnTzCOWXdfeH81nA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [P2PSIP] Term for the peer who is responsible for a specific key 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: When a P2P packet is forwarded through the overlay, it should specify a destination ID, which may be either a resource ID or peer ID. The peer who is responsible for the destination ID will accept and process it and return a response to the request sender. But in the draft-ietf-p2psip-concepts-00, I don't find an appropriate term to define the peer who is the destination of the P2P packets. P2P admitting peer is used in the join operations and does not say exactly that it is the destination of the join packet. Some peers may take the admitting responsibility and the choice of the admitting peer may depend on the joining peer it depends on the choice of the joining peer. Do we need a new term or definition to define this kind of peer? It frequently used in the upcoming peer protocol? Comments? -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Aug 29 03:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQI6G-0004BT-Dg; Wed, 29 Aug 2007 03:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQI6E-0004BG-Hn for p2psip@ietf.org; Wed, 29 Aug 2007 03:36:26 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQI6C-0007kv-Mq for p2psip@ietf.org; Wed, 29 Aug 2007 03:36:26 -0400 Received: from cnshgsbhs01.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id l7T7Z1xW008308; Wed, 29 Aug 2007 15:35:04 +0800 Received: from CNSHGSMBS03.ad4.ad.alcatel.com ([172.24.146.174]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 29 Aug 2007 15:36:19 +0800 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] Term for the peer who is responsible for a specific key X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 29 Aug 2007 15:36:18 +0800 Message-ID: In-Reply-To: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Term for the peer who is responsible for a specific key Thread-Index: AcfqCt7M7MBEOvWnTzCOWXdfeH81nAAAjABg References: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> From: "HUANG Ping B" To: "JiangXingFeng" , "P2PSIP Mailing List" X-OriginalArrivalTime: 29 Aug 2007 07:36:19.0742 (UTC) FILETIME=[4A6D13E0:01C7EA0F] X-imss-version: 2.047 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 dear Jiang I agree with your thinking. but some relevant problems arise: if we define a term to describe "Destination Peer", I think "Proxy Peer","Redirection Peer" and "Original Peer"also should be defined. in draft-ietf-p2psip-concepts-00, above Peers are named "P2PSIP Peer". but for description conveniency , some terms like "Destination Peer","Proxy Peer","Redirection Peer" and "Original Peer" may be defined. Is this redundant? pls give comments, thanks! BR -----Original Message----- From: JiangXingFeng [mailto:jiang.x.f@huawei.com] Sent: Wednesday, August 29, 2007 3:05 PM To: 'P2PSIP Mailing List' Subject: [P2PSIP] Term for the peer who is responsible for a specific key Hi: When a P2P packet is forwarded through the overlay, it should specify a destination ID, which may be either a resource ID or peer ID. The peer who is responsible for the destination ID will accept and process it and return a response to the request sender. But in the draft-ietf-p2psip-concepts-00, I don't find an appropriate term to define the peer who is the destination of the P2P packets.=20 P2P admitting peer is used in the join operations and does not say exactly that it is the destination of the join packet. Some peers may take the admitting responsibility and the choice of the admitting peer may depend on the joining peer it depends on the choice of the joining peer. =20 Do we need a new term or definition to define this kind of peer? It frequently used in the upcoming peer protocol? Comments? -- Jiang XingFeng _______________________________________________ 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 Aug 29 04:47: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 1IQJCh-00081i-Ks; Wed, 29 Aug 2007 04:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJCg-00081d-RS for p2psip@ietf.org; Wed, 29 Aug 2007 04:47:10 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQJCf-0000gZ-L8 for p2psip@ietf.org; Wed, 29 Aug 2007 04:47:10 -0400 Received: by py-out-1112.google.com with SMTP id d32so273981pye for ; Wed, 29 Aug 2007 01:47:09 -0700 (PDT) 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=QgbGwB8ytQE0Th2FlGgEswu0EH5TCOw9bSWi21CNk6bDADfuKLWOOJNyr9cNpR25lLatu46pi7o9NeWII4EnZpIrOpxYd2Q8n3KGpjc5x27Gb7ksdhWV9rc3f8qzPEgax6xpr424PLDWbVbYJ60Nq6/Cy4pjdUEBfzj8SK8oVVo= 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=cWV1Mm3+xrmA291jByu+3te0tSHFPgaa/lvnIsBZ+XJsF2C7X51E+d/XlKi4SKHvk37ZKtHSph7FwSI1Wr2xFZyb/CphidBZouQDpRkrhTUD5cs+SBLt9EaajfMrlhT/7UTqoZkePiWYonul3YOROs/QB8jDXKpWlGNXEE377C4= Received: by 10.65.159.3 with SMTP id l3mr970606qbo.1188377229019; Wed, 29 Aug 2007 01:47:09 -0700 (PDT) Received: by 10.65.84.7 with HTTP; Wed, 29 Aug 2007 01:47:08 -0700 (PDT) Message-ID: <1d38a3350708290147t2e5846e7ibc100c4395ca05da@mail.gmail.com> Date: Wed, 29 Aug 2007 16:47:08 +0800 From: "Hui Deng" To: "HUANG Ping B" Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 guess it depends on protocols between them are different or not, if they are the same, I can't see the necessity to define all of them. -Hui 2007/8/29, HUANG Ping B : > dear Jiang > I agree with your thinking. but some relevant problems arise: if we > define a term to describe "Destination Peer", I think "Proxy > Peer","Redirection Peer" and "Original Peer"also should be defined. in > draft-ietf-p2psip-concepts-00, above Peers are named "P2PSIP Peer". but > for description conveniency , some terms like "Destination Peer","Proxy > Peer","Redirection Peer" and "Original Peer" may be defined. Is this > redundant? pls give comments, thanks! > BR > > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Wednesday, August 29, 2007 3:05 PM > To: 'P2PSIP Mailing List' > Subject: [P2PSIP] Term for the peer who is responsible for a specific > key > > Hi: > > When a P2P packet is forwarded through the overlay, it should specify a > destination ID, which may be either a resource ID or peer ID. The peer > who is responsible for the destination ID will accept and process it and > return a response to the request sender. But in the > draft-ietf-p2psip-concepts-00, I don't find an appropriate term to > define the peer who is the destination of the P2P packets. > > P2P admitting peer is used in the join operations and does not say > exactly that it is the destination of the join packet. Some peers may > take the admitting responsibility and the choice of the admitting peer > may depend on the joining peer it depends on the choice of the joining > peer. > > Do we need a new term or definition to define this kind of peer? It > frequently used in the upcoming peer protocol? > > Comments? > > -- > Jiang XingFeng > > > > > _______________________________________________ > 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 From p2psip-bounces@ietf.org Wed Aug 29 05:03:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJSO-000665-NK; Wed, 29 Aug 2007 05:03:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJSM-00063z-Pc for p2psip@ietf.org; Wed, 29 Aug 2007 05:03:22 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQJSL-0001ij-QS for p2psip@ietf.org; Wed, 29 Aug 2007 05:03:22 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNJ00CO32GE20@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 29 Aug 2007 17:02:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNJ004SA2GDUD@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 29 Aug 2007 17:02:38 +0800 (CST) Received: from x18916 ([10.85.28.238]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNJ00ME82GAWJ@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 29 Aug 2007 17:02:37 +0800 (CST) Date: Wed, 29 Aug 2007 17:02:34 +0800 From: Peili Xu Subject: RE: [P2PSIP] Term for the peer who is responsible for a specific key In-reply-to: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> To: 'JiangXingFeng' , 'P2PSIP Mailing List' Message-id: <03a101c7ea1b$56bad590$ee1c550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfqCt7M7MBEOvWnTzCOWXdfeH81nAAECDpg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Jiang, The entities defined in concept draft has special consern for SIP application. While your consern is for P2P layer routing. I'd espect it to be defined in the peer protocol if required. Do you think peer is enough? Peili -----Original Message----- From: JiangXingFeng [mailto:jiang.x.f@huawei.com] Sent: Wednesday, August 29, 2007 3:05 PM To: 'P2PSIP Mailing List' Subject: [P2PSIP] Term for the peer who is responsible for a specific key Hi: When a P2P packet is forwarded through the overlay, it should specify a destination ID, which may be either a resource ID or peer ID. The peer who is responsible for the destination ID will accept and process it and return a response to the request sender. But in the draft-ietf-p2psip-concepts-00, I don't find an appropriate term to define the peer who is the destination of the P2P packets. P2P admitting peer is used in the join operations and does not say exactly that it is the destination of the join packet. Some peers may take the admitting responsibility and the choice of the admitting peer may depend on the joining peer it depends on the choice of the joining peer. Do we need a new term or definition to define this kind of peer? It frequently used in the upcoming peer protocol? Comments? -- Jiang XingFeng _______________________________________________ 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 Aug 29 06:30:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQKp0-0006Df-1C; Wed, 29 Aug 2007 06:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQKoy-0006DZ-UB for p2psip@ietf.org; Wed, 29 Aug 2007 06:30:48 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQKox-00035l-Lx for p2psip@ietf.org; Wed, 29 Aug 2007 06:30:48 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IQKox-0007SX-0e; Wed, 29 Aug 2007 06:30:47 -0400 In-Reply-To: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> References: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B3C6CA7-3736-4C6B-AB38-385B4E276D31@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key Date: Wed, 29 Aug 2007 06:30:41 -0400 To: JiangXingFeng X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 You are right in that no term has been defined so far for this concept in the Concepts draft. As I recall, none of the current proposals have defined a name for this concept, (Authors of other proposals: please jump in here if my memory if faulty). Feel free to suggest a name and debate it on the list. If some consensus emerges, we will add it to the draft. - Philip On 29-Aug-07, at 03:04 , JiangXingFeng wrote: > Hi: > > When a P2P packet is forwarded through the overlay, it should > specify a > destination ID, which may be either a resource ID or peer ID. The > peer who > is responsible for the destination ID will accept and process it > and return > a response to the request sender. But in the draft-ietf-p2psip- > concepts-00, > I don't find an appropriate term to define the peer who is the > destination > of the P2P packets. > > P2P admitting peer is used in the join operations and does not say > exactly > that it is the destination of the join packet. Some peers may take the > admitting responsibility and the choice of the admitting peer may > depend on > the joining peer it depends on the choice of the joining peer. > > Do we need a new term or definition to define this kind of peer? It > frequently used in the upcoming peer protocol? > > Comments? > > -- > Jiang XingFeng > > > > > _______________________________________________ > 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 Aug 29 08:42:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQMsN-0001kb-Uo; Wed, 29 Aug 2007 08:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQMsN-0001kV-5c for p2psip@ietf.org; Wed, 29 Aug 2007 08:42:27 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQMsL-0006ru-VN for p2psip@ietf.org; Wed, 29 Aug 2007 08:42:27 -0400 Received: by py-out-1112.google.com with SMTP id d32so409474pye for ; Wed, 29 Aug 2007 05:42:25 -0700 (PDT) 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=aWXVcXKGJ7OGoT9+cSncHr5zBnAHOkHqe/d/cDHWNCIZdec928RjPJVZFoVNMtYkKd893y1IcxAmZxHyd9TLa3zdPswb1QSL6OM9BBl6V4CyKHNrSnYPyHy6AC12EcCX0EmAKB4mHEohOip1kGCZbXNP7YMIcnQwIWkxhIubpGU= 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=P945unPa+Vdr3pHxQmrML8D7ljmyiZaIEO0nyNdV1sVx5VoBcaEw2tBHBrGMSQwAKayArP0x/uOR7xtycdgNxMuTkWDzmWA3E64cUUKNZ7BHcL2yQlGMTwRiReyNmeNWOPo4rTARwWNRDJitSGNidKVMyNCFAQC7f4375BDOMIM= Received: by 10.64.242.5 with SMTP id p5mr1412068qbh.1188391345234; Wed, 29 Aug 2007 05:42:25 -0700 (PDT) Received: by 10.65.180.16 with HTTP; Wed, 29 Aug 2007 05:42:25 -0700 (PDT) Message-ID: <4d4304a00708290542w394b725do5664d7b64bde100e@mail.gmail.com> Date: Wed, 29 Aug 2007 08:42:25 -0400 From: "David A. Bryan" To: "Philip Matthews" Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key In-Reply-To: <1B3C6CA7-3736-4C6B-AB38-385B4E276D31@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> <1B3C6CA7-3736-4C6B-AB38-385B4E276D31@magma.ca> X-Google-Sender-Auth: a1cd7ef94659cafb X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 think many people have said "destination of the message" or "responsible peer", but we've never defined a particular term. I've never found a need for a particular term for that in writing drafts, but I guess I wouldn't object if people want one. David On 8/29/07, Philip Matthews wrote: > You are right in that no term has been defined so far for this > concept in the Concepts draft. > > As I recall, none of the current proposals have defined a name for > this concept, > (Authors of other proposals: please jump in here if my memory if > faulty). > > Feel free to suggest a name and debate it on the list. > If some consensus emerges, we will add it to the draft. > > - Philip > > > On 29-Aug-07, at 03:04 , JiangXingFeng wrote: > > > Hi: > > > > When a P2P packet is forwarded through the overlay, it should > > specify a > > destination ID, which may be either a resource ID or peer ID. The > > peer who > > is responsible for the destination ID will accept and process it > > and return > > a response to the request sender. But in the draft-ietf-p2psip- > > concepts-00, > > I don't find an appropriate term to define the peer who is the > > destination > > of the P2P packets. > > > > P2P admitting peer is used in the join operations and does not say > > exactly > > that it is the destination of the join packet. Some peers may take the > > admitting responsibility and the choice of the admitting peer may > > depend on > > the joining peer it depends on the choice of the joining peer. > > > > Do we need a new term or definition to define this kind of peer? It > > frequently used in the upcoming peer protocol? > > > > Comments? > > > > -- > > Jiang XingFeng > > > > > > > > > > _______________________________________________ > > 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 > -- 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 Aug 29 10:53:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQOvM-0006Bn-LC; Wed, 29 Aug 2007 10:53:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQOvK-0006Ai-VW for p2psip@ietf.org; Wed, 29 Aug 2007 10:53:39 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQOvK-0003jX-Ct for p2psip@ietf.org; Wed, 29 Aug 2007 10:53:38 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Wed, 29 Aug 2007 07:52:52 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7TEp5IQ014006; Wed, 29 Aug 2007 07:51:15 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l7TEqYFV008879; Wed, 29 Aug 2007 07:52:35 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 07:52:34 -0700 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 Date: Wed, 29 Aug 2007 07:49:06 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE015@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2P glossary Thread-Index: AcfqCt7M7MBEOvWnTzCOWXdfeH81nAAAjABgAA9linA= References: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> From: "Henry Sinnreich" To: "HUANG Ping B" , "JiangXingFeng" , "P2PSIP Mailing List" X-OriginalArrivalTime: 29 Aug 2007 14:52:34.0314 (UTC) FILETIME=[3BAFCEA0:01C7EA4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: [P2PSIP] P2P glossary 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 are many p2p terms in the vast p2p literature that our P2PSIP WG would be well advised to adopt, for obvious reasons. One of them is there are many other applications beside SIP that actually use and run on p2p :-) I plan to come back to this topic... The origin and destination peers, as far as I remember are called the "source" and "root", but please don't count on my feeble memory. I need to find the references for this. If there is agreement we should use common p2p and DHT terminology, then I would happy to contribute to a p2p glossary. A p2p glossary would also prevent contributors to this WG to reinvent terms in I-Ds and thus contribute to the overall confusion. What do you think? Henry -----Original Message----- From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: Wednesday, August 29, 2007 2:36 AM To: JiangXingFeng; P2PSIP Mailing List Subject: RE: [P2PSIP] Term for the peer who is responsible for a specific key dear Jiang I agree with your thinking. but some relevant problems arise: if we define a term to describe "Destination Peer", I think "Proxy Peer","Redirection Peer" and "Original Peer"also should be defined. in draft-ietf-p2psip-concepts-00, above Peers are named "P2PSIP Peer". but for description conveniency , some terms like "Destination Peer","Proxy Peer","Redirection Peer" and "Original Peer" may be defined. Is this redundant? pls give comments, thanks! BR -----Original Message----- From: JiangXingFeng [mailto:jiang.x.f@huawei.com] Sent: Wednesday, August 29, 2007 3:05 PM To: 'P2PSIP Mailing List' Subject: [P2PSIP] Term for the peer who is responsible for a specific key Hi: When a P2P packet is forwarded through the overlay, it should specify a destination ID, which may be either a resource ID or peer ID. The peer who is responsible for the destination ID will accept and process it and return a response to the request sender. But in the draft-ietf-p2psip-concepts-00, I don't find an appropriate term to define the peer who is the destination of the P2P packets.=20 P2P admitting peer is used in the join operations and does not say exactly that it is the destination of the join packet. Some peers may take the admitting responsibility and the choice of the admitting peer may depend on the joining peer it depends on the choice of the joining peer. =20 Do we need a new term or definition to define this kind of peer? It frequently used in the upcoming peer protocol? Comments? -- Jiang XingFeng _______________________________________________ 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 From p2psip-bounces@ietf.org Wed Aug 29 10:55:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQOxZ-00025g-LR; Wed, 29 Aug 2007 10:55:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQOxX-00023Q-TH for p2psip@ietf.org; Wed, 29 Aug 2007 10:55:55 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQOxX-0003xy-GX for p2psip@ietf.org; Wed, 29 Aug 2007 10:55:55 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNJ001AKIT6GL@usaga01-in.huawei.com> for p2psip@ietf.org; Wed, 29 Aug 2007 07:55:54 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNJ004XLIT4G4@usaga01-in.huawei.com> for p2psip@ietf.org; Wed, 29 Aug 2007 07:55:54 -0700 (PDT) Date: Wed, 29 Aug 2007 09:56:14 -0500 From: Spencer Dawkins Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key To: P2PSIP Mailing List Message-id: <093301c7ea4c$bef59c90$6801a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 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: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> <1B3C6CA7-3736-4C6B-AB38-385B4E276D31@magma.ca> <4d4304a00708290542w394b725do5664d7b64bde100e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 think Peili is correct - as long as we were using SIP for the P2P overlay, we could just use SIP terminology - and agree with XingFeng that if we have a separate P2P transport protocol, it would be useful to define a term for this. Is "responsible peer" unambiguous? I'm looking for something like Responsible Peer - the Peer that stores a specific key in a P2P overlay So, the next question is - we've had some discussion about redundancy as an application-level responsibility ("if you want KEY1 and its attribute stored redundantly, insert KEY1-BACKUP1 and KEY1-BACKUP2 in the DHT as well, and then do lookups for all three, if necessary"), and - we've had some discussion about redundancy as an overlay-level responsiblity ("KEY1 is stored multiple times, and intermediate peers will return KEY1's attribute as long as it is available from *any* peer in the overlay"). I don't know where we are on redundancy now. We may need a "Secondary Responsible Peer", for the peers that handle redundancy, but let's pick the first term now and worry about terms that reflect redundancy later, OK? Thanks, Spencer >I think many people have said "destination of the message" or > "responsible peer", but we've never defined a particular term. I've > never found a need for a particular term for that in writing drafts, > but I guess I wouldn't object if people want one. > > David > > On 8/29/07, Philip Matthews wrote: >> You are right in that no term has been defined so far for this >> concept in the Concepts draft. >> >> As I recall, none of the current proposals have defined a name for >> this concept, >> (Authors of other proposals: please jump in here if my memory if >> faulty). >> >> Feel free to suggest a name and debate it on the list. >> If some consensus emerges, we will add it to the draft. >> >> - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Aug 29 11:50:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPok-00070c-Rj; Wed, 29 Aug 2007 11:50:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPoj-00070L-98 for p2psip@ietf.org; Wed, 29 Aug 2007 11:50:53 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQPoi-0004o7-2g for p2psip@ietf.org; Wed, 29 Aug 2007 11:50:53 -0400 Received: by py-out-1112.google.com with SMTP id d32so598374pye for ; Wed, 29 Aug 2007 08:50:51 -0700 (PDT) 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=njArciJin1IbLwMxZaH6Gm9+mQ+HKztzIqTMV45kEhb4LFYXpDwL5Nb3kvMxhobzkmBLG4dLq9GwG6LP0d4epePF2doBUsby3gpG8BB2Wq5NTGKf9IzzKh9H/jhhu6b4I3jxz1L06BIDxDVsEWtiTlFUu9N5N5vmlr9bSzrVlcY= 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=fQv/laoo0uJ52FMIXq6BMfXil+TZ/wVF02tWmIH2LYtJANpiHqctkz2iU961EI7YcQ6t7Trxlh13sZowUE1PVTYEMSB6SotSESjKJhZ8wePfq00vOdq02mTplwj6UkRe3B+lOcjrAlECDIz7HIlEiv/RRBypEN3ZHJcFpMvf0cY= Received: by 10.65.116.10 with SMTP id t10mr1726103qbm.1188402651598; Wed, 29 Aug 2007 08:50:51 -0700 (PDT) Received: by 10.65.180.16 with HTTP; Wed, 29 Aug 2007 08:50:51 -0700 (PDT) Message-ID: <4d4304a00708290850u59a62abag3777ad2cfd0a5dea@mail.gmail.com> Date: Wed, 29 Aug 2007 11:50:51 -0400 From: "David A. Bryan" To: "Henry Sinnreich" Subject: Re: [P2PSIP] P2P glossary In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE015@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE015@namail5.corp.adobe.com> X-Google-Sender-Auth: b7711349ab14c756 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: P2PSIP Mailing List , HUANG Ping B 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 As individual... I think we should try to include this in the concepts document, rather than a new glossary, but I strongly support Henry's idea of using existing terms if possible, and also for people using the terms in the terminology draft (many of which now represent some very lengthy discussions among many people to reach agreement) rather than inventing new ones. David On 8/29/07, Henry Sinnreich wrote: > There are many p2p terms in the vast p2p literature that our P2PSIP WG > would be well advised to adopt, for obvious reasons. One of them is > there are many other applications beside SIP that actually use and run > on p2p :-) > I plan to come back to this topic... > > The origin and destination peers, as far as I remember are called the > "source" and "root", but please don't count on my feeble memory. I need > to find the references for this. > > If there is agreement we should use common p2p and DHT terminology, then > I would happy to contribute to a p2p glossary. A p2p glossary would also > prevent contributors to this WG to reinvent terms in I-Ds and thus > contribute to the overall confusion. > > What do you think? > > Henry > > -----Original Message----- > From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn] > Sent: Wednesday, August 29, 2007 2:36 AM > To: JiangXingFeng; P2PSIP Mailing List > Subject: RE: [P2PSIP] Term for the peer who is responsible for a > specific key > > dear Jiang > I agree with your thinking. but some relevant problems arise: if we > define a term to describe "Destination Peer", I think "Proxy > Peer","Redirection Peer" and "Original Peer"also should be defined. in > draft-ietf-p2psip-concepts-00, above Peers are named "P2PSIP Peer". but > for description conveniency , some terms like "Destination Peer","Proxy > Peer","Redirection Peer" and "Original Peer" may be defined. Is this > redundant? pls give comments, thanks! > BR > > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Wednesday, August 29, 2007 3:05 PM > To: 'P2PSIP Mailing List' > Subject: [P2PSIP] Term for the peer who is responsible for a specific > key > > Hi: > > When a P2P packet is forwarded through the overlay, it should specify a > destination ID, which may be either a resource ID or peer ID. The peer > who is responsible for the destination ID will accept and process it and > return a response to the request sender. But in the > draft-ietf-p2psip-concepts-00, I don't find an appropriate term to > define the peer who is the destination of the P2P packets. > > P2P admitting peer is used in the join operations and does not say > exactly that it is the destination of the join packet. Some peers may > take the admitting responsibility and the choice of the admitting peer > may depend on the joining peer it depends on the choice of the joining > peer. > > Do we need a new term or definition to define this kind of peer? It > frequently used in the upcoming peer protocol? > > Comments? > > -- > Jiang XingFeng > > > > > _______________________________________________ > 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 > -- 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 Aug 29 11:53:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPqu-0003aD-Md; Wed, 29 Aug 2007 11:53:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPqt-0003a0-E9 for p2psip@ietf.org; Wed, 29 Aug 2007 11:53:07 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQPqr-000538-Vw for p2psip@ietf.org; Wed, 29 Aug 2007 11:53:07 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 179BC280037E1 for ; Wed, 29 Aug 2007 17:53:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pahp47ue+H+D for ; Wed, 29 Aug 2007 17:53:09 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 02517280037E0 for ; Wed, 29 Aug 2007 17:53:04 +0200 (CEST) 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] Term for the peer who is responsible for a specific key X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 29 Aug 2007 17:52:59 +0200 Message-ID: <113091BD57179D4491C19DA7E10CD696016D4B3A@mx1.office> In-Reply-To: <093301c7ea4c$bef59c90$6801a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Term for the peer who is responsible for a specific key Thread-Index: AcfqTMKYv037oMucSWKL5iC3LGb3JQABymKA References: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com><1B3C6CA7-3736-4C6B-AB38-385B4E276D31@magma.ca><4d4304a00708290542w394b725do5664d7b64bde100e@mail.gmail.com> <093301c7ea4c$bef59c90$6801a8c0@china.huawei.com> From: "Jan Seedorf" To: "P2PSIP Mailing List" X-Spam-Score: 1.8 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Dear Henry and Spencer (I am replying to the last two mails on this = thread), In the DHT literature the node responsible for storing the content = belonging to some key is usually referred to as the "root" node for that = particular key. If content for a key is additionally stored at several = nodes in the DHT to provide resilience on the DHT layer, these nodes are = referred to as the "replica roots" for that key. Hope this helps, - Jan Seedorf -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Wednesday, August 29, 2007 4:56 PM To: P2PSIP Mailing List Subject: Re: [P2PSIP] Term for the peer who is responsible for a = specific key I think Peili is correct - as long as we were using SIP for the P2P = overlay, we could just use SIP terminology - and agree with XingFeng = that if we have a separate P2P transport protocol, it would be useful to = define a term for this. Is "responsible peer" unambiguous? I'm looking for something like Responsible Peer - the Peer that stores a specific key in a P2P overlay So, the next question is - we've had some discussion about redundancy as an application-level = responsibility ("if you want KEY1 and its attribute stored redundantly, = insert KEY1-BACKUP1 and KEY1-BACKUP2 in the DHT as well, and then do = lookups for all three, if necessary"), and - we've had some discussion about redundancy as an overlay-level = responsiblity ("KEY1 is stored multiple times, and intermediate peers = will return KEY1's attribute as long as it is available from *any* peer = in the overlay"). I don't know where we are on redundancy now. We may need a "Secondary Responsible Peer", for the peers that handle = redundancy, but let's pick the first term now and worry about terms that = reflect redundancy later, OK? Thanks, Spencer >I think many people have said "destination of the message" or =20 >"responsible peer", but we've never defined a particular term. I've =20 >never found a need for a particular term for that in writing drafts, =20 >but I guess I wouldn't object if people want one. > > David > > On 8/29/07, Philip Matthews wrote: >> You are right in that no term has been defined so far for this=20 >> concept in the Concepts draft. >> >> As I recall, none of the current proposals have defined a name for=20 >> this concept, (Authors of other proposals: please jump in here if my=20 >> memory if faulty). >> >> Feel free to suggest a name and debate it on the list. >> If some consensus emerges, we will add it to the draft. >> >> - 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 Aug 29 13:11:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQR4u-0004GW-0g; Wed, 29 Aug 2007 13:11:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQR4s-00047U-DS for p2psip@ietf.org; Wed, 29 Aug 2007 13:11:38 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQR4s-0000pg-0S for p2psip@ietf.org; Wed, 29 Aug 2007 13:11:38 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IQR4o-0005gp-QE for ; Wed, 29 Aug 2007 19:11:36 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps for id 1IQR4n-00070H-HB; Wed, 29 Aug 2007 19:11:34 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1IQR4n-0000mJ-CD; Wed, 29 Aug 2007 19:11:33 +0200 Received: from [10.16.0.100] (unknown [141.3.71.132]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id EBA372FC015 for ; Wed, 29 Aug 2007 19:11:32 +0200 (CEST) Message-ID: <46D5A8C3.2090806@tm.uka.de> Date: Wed, 29 Aug 2007 19:11:31 +0200 From: Ingmar Baumgart User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: p2psip@ietf.org X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [P2PSIP] P2PSIP demonstrator at P2P2007 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, I'm one of the developers of the OverSim simulation framework and currently working in the area of secure distributed data storage for P2PSIP. One key feature of OverSim is the capability to attach real applications to a simulated DHT for demonstration purposes. We'll show a P2PSIP demo with OverSim at the IEEE P2P2007 conference in Galway next week - the demo abstract is available here: http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf If some of you is attending the conference, it would be great to get some feedback. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Aug 29 13:25:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQRIh-00081y-7Q; Wed, 29 Aug 2007 13:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQRIg-00081t-2p for p2psip@ietf.org; Wed, 29 Aug 2007 13:25:54 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQRIe-0008DI-Oo for p2psip@ietf.org; Wed, 29 Aug 2007 13:25:54 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Wed, 29 Aug 2007 10:25:33 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7THNvIQ011024; Wed, 29 Aug 2007 10:24:01 -0700 (PDT) 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 l7THPHRI000005; Wed, 29 Aug 2007 10:25:29 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 10:25:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] P2PSIP demonstrator at P2P2007 Date: Wed, 29 Aug 2007 10:25:05 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE01C@namail5.corp.adobe.com> In-Reply-To: <46D5A8C3.2090806@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2PSIP demonstrator at P2P2007 Thread-Index: AcfqX7uTAaoPMLypSVGO0SR3ckC+0QAAZ9WA References: <46D5A8C3.2090806@tm.uka.de> From: "Henry Sinnreich" To: "Ingmar Baumgart" , X-OriginalArrivalTime: 29 Aug 2007 17:25:12.0484 (UTC) FILETIME=[8E61A640:01C7EA61] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Ingmar, This is great work! Are there any plans to include peer nodes behind NAT in future work? Thanks, Henry -----Original Message----- From: Ingmar Baumgart [mailto:baumgart@tm.uka.de]=20 Sent: Wednesday, August 29, 2007 12:12 PM To: p2psip@ietf.org Subject: [P2PSIP] P2PSIP demonstrator at P2P2007 Hello, I'm one of the developers of the OverSim simulation framework and currently working in the area of secure distributed data storage for = P2PSIP. One key feature of OverSim is the capability to attach real applications to a simulated DHT for demonstration purposes. We'll show a P2PSIP demo with OverSim at the IEEE P2P2007 conference in Galway next week - the demo abstract is available here: http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf If some of you is attending the conference, it would be great to get some feedback. Regards, Ingmar --=20 Dipl.-Inform. Ingmar Baumgart Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ 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 Aug 29 15:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSnu-0003sm-3p; Wed, 29 Aug 2007 15:02:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSnm-0003qb-RT for p2psip@ietf.org; Wed, 29 Aug 2007 15:02:08 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQSnm-000507-E1 for p2psip@ietf.org; Wed, 29 Aug 2007 15:02:06 -0400 Received: by wa-out-1112.google.com with SMTP id k40so377897wah for ; Wed, 29 Aug 2007 12:02:05 -0700 (PDT) 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:references; b=rD7MLUNRWI5KrPhhv1BWnlDy5wblZA0DNslPV17Uz7zLIZRk+VI2A3Gq0iA1vxvGo0EgtbAmsBoTynLHhcuy+A3sMDfmfMpROwU4PB6e/wkjAa7EZGQUbqd6rXvDGc2ajd1wzj9R0gJrDYzc22W7gW13SVCO+6ax46Lxw/WvxBU= 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=F8uPC6G3/+vcoDaWe5n576eUEbhBsYnsgMu3vw9o44Mlj4cpH5HhZvHDNuo8RXAS5/6f1j/EiBcFLwvBm5MztekKyzzKZIJNZktjBiCGzrkAbGYuc4X3qW992HKZsgkOT3twbI68qfC8P57GuXTaw7Ujn+L+apdVhV9oiqOt43U= Received: by 10.114.92.2 with SMTP id p2mr134357wab.1188414124081; Wed, 29 Aug 2007 12:02:04 -0700 (PDT) Received: by 10.114.110.10 with HTTP; Wed, 29 Aug 2007 12:02:04 -0700 (PDT) Message-ID: <618e24240708291202j197882cas76772b8cb1208cfb@mail.gmail.com> Date: Wed, 29 Aug 2007 21:02:04 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: "David A. Bryan" Subject: Re: [P2PSIP] P2P glossary In-Reply-To: <4d4304a00708290850u59a62abag3777ad2cfd0a5dea@mail.gmail.com> MIME-Version: 1.0 References: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE015@namail5.corp.adobe.com> <4d4304a00708290850u59a62abag3777ad2cfd0a5dea@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Henry Sinnreich , P2PSIP Mailing List , HUANG Ping B 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="===============0003813784==" Errors-To: p2psip-bounces@ietf.org --===============0003813784== Content-Type: multipart/alternative; boundary="----=_Part_2902_26586634.1188414124020" ------=_Part_2902_26586634.1188414124020 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, On 29/08/2007, David A. Bryan wrote: > > I think we should try to include this in the concepts document, rather > than a new glossary, I support this idea. Together with some folks -from p2psip mail list- we are developing a framework for providing advanced communication services in p2psip overlays and we are experiencing some problems with p2p and DHT terminology. By the way, if someone wants to join us it is welcome. Our goal is to submit this work to the WG as an Internet Draft. Thanks, Victor Pascual ------=_Part_2902_26586634.1188414124020 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

On 29/08/2007, David A. Bryan <dbryan@sipeerior.com> wrote:
I think we should try to include this in the concepts document, rather
than a new glossary,

I support this idea.

Together with some folks -from p2psip mail list- we are developing a framework for providing advanced communication services in  p2psip overlays and we are experiencing some problems with p2p and DHT terminology.

By the way, if someone wants to join us it is welcome. Our goal is to submit this work to the WG as an Internet Draft.

Thanks,
Victor Pascual

------=_Part_2902_26586634.1188414124020-- --===============0003813784== 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 --===============0003813784==-- From p2psip-bounces@ietf.org Wed Aug 29 21:25:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQYmo-0002Fx-S4; Wed, 29 Aug 2007 21:25:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQYmk-0002C4-Bh for p2psip@ietf.org; Wed, 29 Aug 2007 21:25:26 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQYmj-0002dn-C1 for p2psip@ietf.org; Wed, 29 Aug 2007 21:25:26 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNK00EQMBX71B@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 30 Aug 2007 09:24:43 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNK001WFBX5XG@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 30 Aug 2007 09:24:43 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNK00JD2BX2V2@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 30 Aug 2007 09:24:41 +0800 (CST) Date: Thu, 30 Aug 2007 09:24:37 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Term for the peer who is responsible for a specific key In-reply-to: <113091BD57179D4491C19DA7E10CD696016D4B3A@mx1.office> To: 'Jan Seedorf' , 'P2PSIP Mailing List' Message-id: <011c01c7eaa4$87c9e480$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcfqTMKYv037oMucSWKL5iC3LGb3JQABymKAABQO3cA= X-Spam-Score: 1.8 (+) 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, I suggest that the concept draft would adopt those terms - "P2PSIP root peer" and "P2PSIP replica root peer", they are clear and useful for contributors to P2PSIP WG. --Hewen -----Original Message----- From: Jan Seedorf [mailto:Jan.Seedorf@netlab.nec.de] Sent: 2007?8?29? 23:53 To: P2PSIP Mailing List Subject: RE: [P2PSIP] Term for the peer who is responsible for a specific key Dear Henry and Spencer (I am replying to the last two mails on this thread), In the DHT literature the node responsible for storing the content belonging to some key is usually referred to as the "root" node for that particular key. If content for a key is additionally stored at several nodes in the DHT to provide resilience on the DHT layer, these nodes are referred to as the "replica roots" for that key. Hope this helps, - Jan Seedorf -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] Sent: Wednesday, August 29, 2007 4:56 PM To: P2PSIP Mailing List Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key I think Peili is correct - as long as we were using SIP for the P2P overlay, we could just use SIP terminology - and agree with XingFeng that if we have a separate P2P transport protocol, it would be useful to define a term for this. Is "responsible peer" unambiguous? I'm looking for something like Responsible Peer - the Peer that stores a specific key in a P2P overlay So, the next question is - we've had some discussion about redundancy as an application-level responsibility ("if you want KEY1 and its attribute stored redundantly, insert KEY1-BACKUP1 and KEY1-BACKUP2 in the DHT as well, and then do lookups for all three, if necessary"), and - we've had some discussion about redundancy as an overlay-level responsiblity ("KEY1 is stored multiple times, and intermediate peers will return KEY1's attribute as long as it is available from *any* peer in the overlay"). I don't know where we are on redundancy now. We may need a "Secondary Responsible Peer", for the peers that handle redundancy, but let's pick the first term now and worry about terms that reflect redundancy later, OK? Thanks, Spencer >I think many people have said "destination of the message" or >"responsible peer", but we've never defined a particular term. I've >never found a need for a particular term for that in writing drafts, >but I guess I wouldn't object if people want one. > > David > > On 8/29/07, Philip Matthews wrote: >> You are right in that no term has been defined so far for this >> concept in the Concepts draft. >> >> As I recall, none of the current proposals have defined a name for >> this concept, (Authors of other proposals: please jump in here if my >> memory if faulty). >> >> Feel free to suggest a name and debate it on the list. >> If some consensus emerges, we will add it to the draft. >> >> - 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 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Aug 29 21:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQYpH-0003t5-LM; Wed, 29 Aug 2007 21:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQYpE-0003sv-Tn for p2psip@ietf.org; Wed, 29 Aug 2007 21:28:01 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQYpC-0008RW-PE for p2psip@ietf.org; Wed, 29 Aug 2007 21:28:00 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNK006LOC1HIZ@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 30 Aug 2007 09:27:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNK00K54C1GCY@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 30 Aug 2007 09:27:17 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNK00JZJC1CV2@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 30 Aug 2007 09:27:16 +0800 (CST) Date: Thu, 30 Aug 2007 09:27:11 +0800 From: JiangXingFeng In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D223AE015@namail5.corp.adobe.com> To: 'Henry Sinnreich' , 'HUANG Ping B' , 'P2PSIP Mailing List' Message-id: <001501c7eaa4$e3f88680$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfqCt7M7MBEOvWnTzCOWXdfeH81nAAAjABgAA9linAAFmyasA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [P2PSIP] RE: P2P glossary 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, Henry: This idea is what I intend to achieve. In order to make P2PSIP contributions use the glossary based on the same understanding among the P2PSIP community, we should define a uniform suit of glossary. I am willing to join this contribution. Regards! -- Jiang XingFeng > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, August 29, 2007 10:49 PM > To: HUANG Ping B; JiangXingFeng; P2PSIP Mailing List > Subject: P2P glossary > > There are many p2p terms in the vast p2p literature that our P2PSIP WG > would be well advised to adopt, for obvious reasons. One of them is > there are many other applications beside SIP that actually use and run > on p2p :-) > I plan to come back to this topic... > > The origin and destination peers, as far as I remember are called the > "source" and "root", but please don't count on my feeble memory. I need > to find the references for this. > > If there is agreement we should use common p2p and DHT terminology, then > I would happy to contribute to a p2p glossary. A p2p glossary would also > prevent contributors to this WG to reinvent terms in I-Ds and thus > contribute to the overall confusion. > > What do you think? > > Henry > > -----Original Message----- > From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn] > Sent: Wednesday, August 29, 2007 2:36 AM > To: JiangXingFeng; P2PSIP Mailing List > Subject: RE: [P2PSIP] Term for the peer who is responsible for a > specific key > > dear Jiang > I agree with your thinking. but some relevant problems arise: if we > define a term to describe "Destination Peer", I think "Proxy > Peer","Redirection Peer" and "Original Peer"also should be defined. in > draft-ietf-p2psip-concepts-00, above Peers are named "P2PSIP Peer". but > for description conveniency , some terms like "Destination Peer","Proxy > Peer","Redirection Peer" and "Original Peer" may be defined. Is this > redundant? pls give comments, thanks! > BR > > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Wednesday, August 29, 2007 3:05 PM > To: 'P2PSIP Mailing List' > Subject: [P2PSIP] Term for the peer who is responsible for a specific > key > > Hi: > > When a P2P packet is forwarded through the overlay, it should specify a > destination ID, which may be either a resource ID or peer ID. The peer > who is responsible for the destination ID will accept and process it and > return a response to the request sender. But in the > draft-ietf-p2psip-concepts-00, I don't find an appropriate term to > define the peer who is the destination of the P2P packets. > > P2P admitting peer is used in the join operations and does not say > exactly that it is the destination of the join packet. Some peers may > take the admitting responsibility and the choice of the admitting peer > may depend on the joining peer it depends on the choice of the joining > peer. > > Do we need a new term or definition to define this kind of peer? It > frequently used in the upcoming peer protocol? > > Comments? > > -- > Jiang XingFeng > > > > > _______________________________________________ > 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 From p2psip-bounces@ietf.org Wed Aug 29 21:33:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQYug-0002Ox-Vt; Wed, 29 Aug 2007 21:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQYub-0002Dg-Ks for p2psip@ietf.org; Wed, 29 Aug 2007 21:33:35 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQYuZ-000072-C5 for p2psip@ietf.org; Wed, 29 Aug 2007 21:33:33 -0400 Received: from cnshgsbhs01.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id l7U1Vwq9025185; Thu, 30 Aug 2007 09:31:58 +0800 Received: from CNSHGSMBS03.ad4.ad.alcatel.com ([172.24.146.174]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 30 Aug 2007 09:33:16 +0800 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] P2P glossary X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 30 Aug 2007 09:33:16 +0800 Message-ID: In-Reply-To: <4d4304a00708290850u59a62abag3777ad2cfd0a5dea@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2P glossary Thread-Index: AcfqVPUJp1NA7owERuqYRjh0p8SjXwATmJ7Q References: <003b01c7ea0a$df1200a0$6905a40a@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE015@namail5.corp.adobe.com> <4d4304a00708290850u59a62abag3777ad2cfd0a5dea@mail.gmail.com> From: "HUANG Ping B" To: "David A. Bryan" , "Henry Sinnreich" X-OriginalArrivalTime: 30 Aug 2007 01:33:16.0979 (UTC) FILETIME=[BD4CF830:01C7EAA5] X-imss-version: 2.047 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 Dear ALL sorry for later reply, when you are working I'm just in sleep and maybe vice-versa. one exception is that your sun and my sun are in the sky in the same time.:)!... I support David's suggestions, and strongly support Herry's suggestion that existing terms should be used if possible. more terms emerging is not good! BR huang ping -----Original Message----- From: amelampus@gmail.com [mailto:amelampus@gmail.com] On Behalf Of David A. Bryan Sent: Wednesday, August 29, 2007 11:51 PM To: Henry Sinnreich Cc: HUANG Ping B; JiangXingFeng; P2PSIP Mailing List Subject: Re: [P2PSIP] P2P glossary As individual... I think we should try to include this in the concepts document, rather than a new glossary, but I strongly support Henry's idea of using existing terms if possible, and also for people using the terms in the terminology draft (many of which now represent some very lengthy discussions among many people to reach agreement) rather than inventing new ones. David On 8/29/07, Henry Sinnreich wrote: > There are many p2p terms in the vast p2p literature that our P2PSIP WG > would be well advised to adopt, for obvious reasons. One of them is=20 > there are many other applications beside SIP that actually use and run > on p2p :-) I plan to come back to this topic... > > The origin and destination peers, as far as I remember are called the=20 > "source" and "root", but please don't count on my feeble memory. I=20 > need to find the references for this. > > If there is agreement we should use common p2p and DHT terminology,=20 > then I would happy to contribute to a p2p glossary. A p2p glossary=20 > would also prevent contributors to this WG to reinvent terms in I-Ds=20 > and thus contribute to the overall confusion. > > What do you think? > > Henry > > -----Original Message----- > From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn] > Sent: Wednesday, August 29, 2007 2:36 AM > To: JiangXingFeng; P2PSIP Mailing List > Subject: RE: [P2PSIP] Term for the peer who is responsible for a=20 > specific key > > dear Jiang > I agree with your thinking. but some relevant problems arise: if=20 > we define a term to describe "Destination Peer", I think "Proxy=20 > Peer","Redirection Peer" and "Original Peer"also should be defined. in > draft-ietf-p2psip-concepts-00, above Peers are named "P2PSIP Peer".=20 > but for description conveniency , some terms like "Destination=20 > Peer","Proxy Peer","Redirection Peer" and "Original Peer" may be=20 > defined. Is this redundant? pls give comments, thanks! > BR > > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Wednesday, August 29, 2007 3:05 PM > To: 'P2PSIP Mailing List' > Subject: [P2PSIP] Term for the peer who is responsible for a specific=20 > key > > Hi: > > When a P2P packet is forwarded through the overlay, it should specify=20 > a destination ID, which may be either a resource ID or peer ID. The=20 > peer who is responsible for the destination ID will accept and process > it and return a response to the request sender. But in the=20 > draft-ietf-p2psip-concepts-00, I don't find an appropriate term to=20 > define the peer who is the destination of the P2P packets. > > P2P admitting peer is used in the join operations and does not say=20 > exactly that it is the destination of the join packet. Some peers may=20 > take the admitting responsibility and the choice of the admitting peer > may depend on the joining peer it depends on the choice of the joining > peer. > > Do we need a new term or definition to define this kind of peer? It=20 > frequently used in the upcoming peer protocol? > > Comments? > > -- > Jiang XingFeng > > > > > _______________________________________________ > 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 > -- 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 Thu Aug 30 11:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQmDB-0007N2-5b; Thu, 30 Aug 2007 11:45:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQmDA-0007Mx-77 for p2psip@ietf.org; Thu, 30 Aug 2007 11:45:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQmD9-0004pe-D5 for p2psip@ietf.org; Thu, 30 Aug 2007 11:45:36 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IQmD8-0007w4-2H; Thu, 30 Aug 2007 11:45:34 -0400 In-Reply-To: <011c01c7eaa4$87c9e480$5105a40a@china.huawei.com> References: <011c01c7eaa4$87c9e480$5105a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0142F8A2-D96A-4956-9873-DE3454C2FB99@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key Date: Thu, 30 Aug 2007 11:45:32 -0400 To: Zheng Hewen X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 1.8 (+) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: 'Jan Seedorf' , '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 personally have never heard of the term "root peer" before, and I would never guess that it mean the peer that stores the content associated with a key. Can someone explain where this term comes from? What is it the root of? - Philip On 29-Aug-07, at 21:24 , Zheng Hewen wrote: > Hi, > > I suggest that the concept draft would adopt those terms - "P2PSIP > root peer" and "P2PSIP replica root peer", they are clear > and useful for contributors to P2PSIP WG. > > --Hewen > > -----Original Message----- > From: Jan Seedorf [mailto:Jan.Seedorf@netlab.nec.de] > Sent: 2007?8?29? 23:53 > To: P2PSIP Mailing List > Subject: RE: [P2PSIP] Term for the peer who is responsible for a > specific key > > Dear Henry and Spencer (I am replying to the last two mails on this > thread), > > In the DHT literature the node responsible for storing the content > belonging to some key is usually referred to as the > "root" node for that particular key. If content for a key is > additionally stored at several nodes in the DHT to provide > resilience on the DHT layer, these nodes are referred to as the > "replica roots" for that key. > > Hope this helps, > > - Jan Seedorf > > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Wednesday, August 29, 2007 4:56 PM > To: P2PSIP Mailing List > Subject: Re: [P2PSIP] Term for the peer who is responsible for a > specific key > > I think Peili is correct - as long as we were using SIP for the P2P > overlay, we could just use SIP terminology - and agree > with XingFeng that if we have a separate P2P transport protocol, it > would be useful to define a term for this. > > Is "responsible peer" unambiguous? I'm looking for something like > > Responsible Peer - the Peer that stores a specific key in a P2P > overlay > > So, the next question is > > - we've had some discussion about redundancy as an application- > level responsibility ("if you want KEY1 and its attribute > stored redundantly, insert KEY1-BACKUP1 and KEY1-BACKUP2 in the DHT > as well, and then do lookups for all three, if > necessary"), and > > - we've had some discussion about redundancy as an overlay-level > responsiblity ("KEY1 is stored multiple times, and > intermediate peers will return KEY1's attribute as long as it is > available from *any* peer in the overlay"). > > I don't know where we are on redundancy now. > > We may need a "Secondary Responsible Peer", for the peers that > handle redundancy, but let's pick the first term now and > worry about terms that reflect redundancy later, OK? > > Thanks, > > Spencer > > >> I think many people have said "destination of the message" or >> "responsible peer", but we've never defined a particular term. I've >> never found a need for a particular term for that in writing drafts, >> but I guess I wouldn't object if people want one. >> >> David >> >> On 8/29/07, Philip Matthews wrote: >>> You are right in that no term has been defined so far for this >>> concept in the Concepts draft. >>> >>> As I recall, none of the current proposals have defined a name for >>> this concept, (Authors of other proposals: please jump in here if my >>> memory if faulty). >>> >>> Feel free to suggest a name and debate it on the list. >>> If some consensus emerges, we will add it to the draft. >>> >>> - 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 > > > > > _______________________________________________ > 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 Thu Aug 30 11:55:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQmN1-0001By-Fb; Thu, 30 Aug 2007 11:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQmMz-0001Aj-JQ for p2psip@ietf.org; Thu, 30 Aug 2007 11:55:45 -0400 Received: from alnrmhc16.comcast.net ([204.127.225.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQmMy-0008DK-CY for p2psip@ietf.org; Thu, 30 Aug 2007 11:55:45 -0400 Received: from home2000 (c-76-21-99-127.hsd1.ca.comcast.net[76.21.99.127]) by comcast.net (alnrmhc16) with SMTP id <20070830155543b1600s33qce>; Thu, 30 Aug 2007 15:55:43 +0000 Message-ID: <001801c7eb1e$ccb92360$030aa8c0@comcast.net> From: "Peter Pan" To: "Philip Matthews" , "Zheng Hewen" References: <011c01c7eaa4$87c9e480$5105a40a@china.huawei.com> <0142F8A2-D96A-4956-9873-DE3454C2FB99@magma.ca> Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key Date: Thu, 30 Aug 2007 08:59:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-Spam-Score: 1.8 (+) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: 'Jan Seedorf' , '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 neither have i, though i did heard of "root beer". peter ----- Original Message ----- From: "Philip Matthews" To: "Zheng Hewen" Cc: "'Jan Seedorf'" ; "'P2PSIP Mailing List'" Sent: Thursday, August 30, 2007 8:45 AM Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key > I personally have never heard of the term "root peer" before, and I > would never guess that it mean the peer that stores the content > associated with a key. Can someone explain where this term comes > from? What is it the root of? > > - Philip > > On 29-Aug-07, at 21:24 , Zheng Hewen wrote: > > > Hi, > > > > I suggest that the concept draft would adopt those terms - "P2PSIP > > root peer" and "P2PSIP replica root peer", they are clear > > and useful for contributors to P2PSIP WG. > > > > --Hewen > > > > -----Original Message----- > > From: Jan Seedorf [mailto:Jan.Seedorf@netlab.nec.de] > > Sent: 2007?8?29? 23:53 > > To: P2PSIP Mailing List > > Subject: RE: [P2PSIP] Term for the peer who is responsible for a > > specific key > > > > Dear Henry and Spencer (I am replying to the last two mails on this > > thread), > > > > In the DHT literature the node responsible for storing the content > > belonging to some key is usually referred to as the > > "root" node for that particular key. If content for a key is > > additionally stored at several nodes in the DHT to provide > > resilience on the DHT layer, these nodes are referred to as the > > "replica roots" for that key. > > > > Hope this helps, > > > > - Jan Seedorf > > > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > > Sent: Wednesday, August 29, 2007 4:56 PM > > To: P2PSIP Mailing List > > Subject: Re: [P2PSIP] Term for the peer who is responsible for a > > specific key > > > > I think Peili is correct - as long as we were using SIP for the P2P > > overlay, we could just use SIP terminology - and agree > > with XingFeng that if we have a separate P2P transport protocol, it > > would be useful to define a term for this. > > > > Is "responsible peer" unambiguous? I'm looking for something like > > > > Responsible Peer - the Peer that stores a specific key in a P2P > > overlay > > > > So, the next question is > > > > - we've had some discussion about redundancy as an application- > > level responsibility ("if you want KEY1 and its attribute > > stored redundantly, insert KEY1-BACKUP1 and KEY1-BACKUP2 in the DHT > > as well, and then do lookups for all three, if > > necessary"), and > > > > - we've had some discussion about redundancy as an overlay-level > > responsiblity ("KEY1 is stored multiple times, and > > intermediate peers will return KEY1's attribute as long as it is > > available from *any* peer in the overlay"). > > > > I don't know where we are on redundancy now. > > > > We may need a "Secondary Responsible Peer", for the peers that > > handle redundancy, but let's pick the first term now and > > worry about terms that reflect redundancy later, OK? > > > > Thanks, > > > > Spencer > > > > > >> I think many people have said "destination of the message" or > >> "responsible peer", but we've never defined a particular term. I've > >> never found a need for a particular term for that in writing drafts, > >> but I guess I wouldn't object if people want one. > >> > >> David > >> > >> On 8/29/07, Philip Matthews wrote: > >>> You are right in that no term has been defined so far for this > >>> concept in the Concepts draft. > >>> > >>> As I recall, none of the current proposals have defined a name for > >>> this concept, (Authors of other proposals: please jump in here if my > >>> memory if faulty). > >>> > >>> Feel free to suggest a name and debate it on the list. > >>> If some consensus emerges, we will add it to the draft. > >>> > >>> - 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 > > > > > > > > > > _______________________________________________ > > 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 From p2psip-bounces@ietf.org Thu Aug 30 12:37:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQn1Z-0006m5-0i; Thu, 30 Aug 2007 12:37:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQn1X-0006lx-Af for p2psip@ietf.org; Thu, 30 Aug 2007 12:37:39 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQn1W-0006kv-JX for p2psip@ietf.org; Thu, 30 Aug 2007 12:37:39 -0400 Received: from source ([192.150.11.134]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Thu, 30 Aug 2007 09:37:21 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7UGZmIQ006720; Thu, 30 Aug 2007 09:35:48 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7UGapRg005596; Thu, 30 Aug 2007 09:37:20 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 09:37:15 -0700 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] Term for the peer who is responsible for a specific key Date: Thu, 30 Aug 2007 09:37:04 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE026@namail5.corp.adobe.com> In-Reply-To: <001801c7eb1e$ccb92360$030aa8c0@comcast.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Term for the peer who is responsible for a specific key Thread-Index: AcfrHkORJfrFJSedTOO2QpnLA1qRcgAA3bIg References: <011c01c7eaa4$87c9e480$5105a40a@china.huawei.com><0142F8A2-D96A-4956-9873-DE3454C2FB99@magma.ca> <001801c7eb1e$ccb92360$030aa8c0@comcast.net> From: "Henry Sinnreich" To: "Peter Pan" , "Philip Matthews" , "Zheng Hewen" X-OriginalArrivalTime: 30 Aug 2007 16:37:15.0036 (UTC) FILETIME=[05B3ADC0:01C7EB24] X-Spam-Score: 1.8 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Jan Seedorf , 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 As Jan Seedorf has already indicated (see below), the root in a DHT is well defined and documented. Here are three examples, including one from the P2P SIP WG I-D :-)> If anything, this trail shows the need for a DHT and P2PSIP glossary. Henry A. Chord vn. 0.6.3 released on May 3, 2007 features: * The root node of routing creates and removes replicas on a DHT instead of the requester if replication is enabled.=20 * In case of DHT put, get and remove, a node requests spare root candidates to be prepared for failure of the root node.=20 See http://overlayweaver.sourceforge.net/news/=20 B. Chord and Bamboo "The DHT assigns every key in the identifier space to a node, which is called the root (or the successor) of the key. The main primitive that DHTs support is lookup, in which a node can efficiently discover a key's root. The lookup protocol greedily traverses the nodes of the DHT, progressing closer to the root of the key at each step." See http://srhea.net/papers/ntr-worlds05.pdf=20 C. In the IETF P2P SIP WG: "Req 7-5: The peer protocol MUST accommodate a DHT for a fast routing=20 algorithm that minimizes hop count to the root node..." See http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-requirements-00.txt=20 Henry -----Original Message----- From: Peter Pan [mailto:huang-ming.pan@comcast.net]=20 Sent: Thursday, August 30, 2007 11:00 AM To: Philip Matthews; Zheng Hewen Cc: 'Jan Seedorf'; 'P2PSIP Mailing List' Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key neither have i, though i did heard of "root beer". peter ----- Original Message ----- From: "Philip Matthews" To: "Zheng Hewen" Cc: "'Jan Seedorf'" ; "'P2PSIP Mailing List'" Sent: Thursday, August 30, 2007 8:45 AM Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key > I personally have never heard of the term "root peer" before, and I > would never guess that it mean the peer that stores the content > associated with a key. Can someone explain where this term comes > from? What is it the root of? > > - Philip > > On 29-Aug-07, at 21:24 , Zheng Hewen wrote: > > > Hi, > > > > I suggest that the concept draft would adopt those terms - "P2PSIP > > root peer" and "P2PSIP replica root peer", they are clear > > and useful for contributors to P2PSIP WG. > > > > --Hewen > > > > -----Original Message----- > > From: Jan Seedorf [mailto:Jan.Seedorf@netlab.nec.de] > > Sent: 2007?8?29? 23:53 > > To: P2PSIP Mailing List > > Subject: RE: [P2PSIP] Term for the peer who is responsible for a > > specific key > > > > Dear Henry and Spencer (I am replying to the last two mails on this > > thread), > > > > In the DHT literature the node responsible for storing the content > > belonging to some key is usually referred to as the > > "root" node for that particular key. If content for a key is > > additionally stored at several nodes in the DHT to provide > > resilience on the DHT layer, these nodes are referred to as the > > "replica roots" for that key. > > > > Hope this helps, > > > > - Jan Seedorf > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Aug 30 21:31:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQvMR-0000ER-OR; Thu, 30 Aug 2007 21:31:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQvMQ-0000DN-F6 for p2psip@ietf.org; Thu, 30 Aug 2007 21:31:46 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQvMP-0002LU-94 for p2psip@ietf.org; Thu, 30 Aug 2007 21:31:46 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNM009D46VTCF@szxga02-in.huawei.com> for p2psip@ietf.org; Fri, 31 Aug 2007 09:31:06 +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 <0JNM0092J6VTZ4@szxga02-in.huawei.com> for p2psip@ietf.org; Fri, 31 Aug 2007 09:31:05 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNM00JB16VO3I@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 31 Aug 2007 09:31:04 +0800 (CST) Date: Fri, 31 Aug 2007 09:30:59 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Term for the peer who is responsible for a specific key In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D223AE026@namail5.corp.adobe.com> To: 'Henry Sinnreich' , 'Peter Pan' , 'Philip Matthews' Message-id: <006f01c7eb6e$96057b20$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcfrHkORJfrFJSedTOO2QpnLA1qRcgAA3bIgABLgHBA= X-Spam-Score: 1.8 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 'Jan Seedorf' , '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 Abundant info! No more supplement. In fact, I do not care "root peer" or "responsible peer" for the term about the peer which has the responsibility to store a specific key; I think that we need uniform and explicit definitions for those terms in one distinct glossary I-D or the concept draft, which are useful and convenient to the contributors of P2PSIP WG. --Hewen -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?8?31? 0:37 To: Peter Pan; Philip Matthews; Zheng Hewen Cc: Jan Seedorf; P2PSIP Mailing List Subject: RE: [P2PSIP] Term for the peer who is responsible for a specific key As Jan Seedorf has already indicated (see below), the root in a DHT is well defined and documented. Here are three examples, including one from the P2P SIP WG I-D :-)> If anything, this trail shows the need for a DHT and P2PSIP glossary. Henry A. Chord vn. 0.6.3 released on May 3, 2007 features: * The root node of routing creates and removes replicas on a DHT instead of the requester if replication is enabled. * In case of DHT put, get and remove, a node requests spare root candidates to be prepared for failure of the root node. See http://overlayweaver.sourceforge.net/news/ B. Chord and Bamboo "The DHT assigns every key in the identifier space to a node, which is called the root (or the successor) of the key. The main primitive that DHTs support is lookup, in which a node can efficiently discover a key's root. The lookup protocol greedily traverses the nodes of the DHT, progressing closer to the root of the key at each step." See http://srhea.net/papers/ntr-worlds05.pdf C. In the IETF P2P SIP WG: "Req 7-5: The peer protocol MUST accommodate a DHT for a fast routing algorithm that minimizes hop count to the root node..." See http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-requirements-00.txt Henry -----Original Message----- From: Peter Pan [mailto:huang-ming.pan@comcast.net] Sent: Thursday, August 30, 2007 11:00 AM To: Philip Matthews; Zheng Hewen Cc: 'Jan Seedorf'; 'P2PSIP Mailing List' Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key neither have i, though i did heard of "root beer". peter ----- Original Message ----- From: "Philip Matthews" To: "Zheng Hewen" Cc: "'Jan Seedorf'" ; "'P2PSIP Mailing List'" Sent: Thursday, August 30, 2007 8:45 AM Subject: Re: [P2PSIP] Term for the peer who is responsible for a specific key > I personally have never heard of the term "root peer" before, and I > would never guess that it mean the peer that stores the content > associated with a key. Can someone explain where this term comes from? > What is it the root of? > > - Philip > > On 29-Aug-07, at 21:24 , Zheng Hewen wrote: > > > Hi, > > > > I suggest that the concept draft would adopt those terms - "P2PSIP > > root peer" and "P2PSIP replica root peer", they are clear and useful > > for contributors to P2PSIP WG. > > > > --Hewen > > > > -----Original Message----- > > From: Jan Seedorf [mailto:Jan.Seedorf@netlab.nec.de] > > Sent: 2007?8?29? 23:53 > > To: P2PSIP Mailing List > > Subject: RE: [P2PSIP] Term for the peer who is responsible for a > > specific key > > > > Dear Henry and Spencer (I am replying to the last two mails on this > > thread), > > > > In the DHT literature the node responsible for storing the content > > belonging to some key is usually referred to as the "root" node for > > that particular key. If content for a key is additionally stored at > > several nodes in the DHT to provide resilience on the DHT layer, > > these nodes are referred to as the "replica roots" for that key. > > > > Hope this helps, > > > > - Jan Seedorf > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Aug 31 10:24:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR7QR-00066n-P2; Fri, 31 Aug 2007 10:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR7QQ-00064l-5J for p2psip@ietf.org; Fri, 31 Aug 2007 10:24:42 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR7QO-0007EU-Jk for p2psip@ietf.org; Fri, 31 Aug 2007 10:24:42 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IR7QK-0000yr-Vv; Fri, 31 Aug 2007 16:24:39 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IR7QJ-0005VG-6K; Fri, 31 Aug 2007 16:24:36 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IR7QJ-00015m-0G; Fri, 31 Aug 2007 16:24:35 +0200 Received: from [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4] (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 6FBC82FC00D; Fri, 31 Aug 2007 16:24:34 +0200 (CEST) Message-ID: <46D824A0.70607@tm.uka.de> Date: Fri, 31 Aug 2007 16:24:32 +0200 From: Ingmar Baumgart User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] P2PSIP demonstrator at P2P2007 References: <46D5A8C3.2090806@tm.uka.de> <24CCCC428EFEA2469BF046DB3C7A8D223AE01C@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE01C@namail5.corp.adobe.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Hello Henry, currently there are no plans to simulate NAT in OverSim. But we're working on a simulator extension to model supernodes that can be located in the backbone. Depending on what you actually want to model, this could maybe also be used to simulate some of the effects of peer nodes behind NAT. In our current work we're focusing on the comparision of overlay protocols (Chord, Pastry, Koorde, Kademlia and Broose) in the face of security and reliability (among equal peers). Regards, Ingmar Henry Sinnreich wrote: > Ingmar, > > This is great work! > > Are there any plans to include peer nodes behind NAT in future work? > > Thanks, Henry > > -----Original Message----- > From: Ingmar Baumgart [mailto:baumgart@tm.uka.de] > Sent: Wednesday, August 29, 2007 12:12 PM > To: p2psip@ietf.org > Subject: [P2PSIP] P2PSIP demonstrator at P2P2007 > > Hello, > > I'm one of the developers of the OverSim simulation framework and > currently working in the area of secure distributed data storage for P2PSIP. > > One key feature of OverSim is the capability to attach real applications > to a simulated DHT for demonstration purposes. We'll show a P2PSIP demo > with OverSim at the IEEE P2P2007 conference in Galway next week - the > demo abstract is available here: > > http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf > > If some of you is attending the conference, it would be great to get > some feedback. > > Regards, > Ingmar > -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Aug 31 17:28:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRE2P-0000M0-Mz; Fri, 31 Aug 2007 17:28:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRE2P-0000Lu-7d for p2psip@ietf.org; Fri, 31 Aug 2007 17:28:21 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRE2O-000479-NX for p2psip@ietf.org; Fri, 31 Aug 2007 17:28:21 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IRE2L-0002G8-1z; Fri, 31 Aug 2007 17:28:17 -0400 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: Fri, 31 Aug 2007 17:28:17 -0400 To: P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [P2PSIP] Concepts draft 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 authors of the Concepts draft have been discussing how we might advance this draft in preparation for the next IETF meeting. There has been some discussion on the list recently on additional terms that might be added to the draft, and we are following this discussion closely. Once this resolves, we will propose text to cover this. There is also the question of whether the P2P layer should be distinct from the SIP layer. In the Chicago meeting, there seemed to be a strong feeling that this was the right way to do, so I would like to official ask the chairs whether we can consider this a WG decision. If so, then we will document this in the draft. However, none of this is pointing to a major revision. Most of the questions that are currently listed in the draft, or that were listed in the so-called "Joint Presentation" in Chicago remain unresolved. In the opinion of the authors, the next major revision needs to wait until the WG comes up with a clearer view of which way it wants to go. In particular, the 6 proposals that were presented in Chicago need time to mature and potentially merge before a clear consensus emerges. So right now we envision only a minor update for the Vancouver meeting. Comments? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Aug 31 17:48:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRELp-0002XR-Ep; Fri, 31 Aug 2007 17:48:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRELo-0002T4-PD for p2psip@ietf.org; Fri, 31 Aug 2007 17:48:24 -0400 Received: from chip2og55.obsmtp.com ([64.18.13.47]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRELo-0004VK-AW for p2psip@ietf.org; Fri, 31 Aug 2007 17:48:24 -0400 Received: from source ([192.150.11.134]) by chip2ob55.postini.com ([64.18.5.12]) with SMTP; Fri, 31 Aug 2007 14:48:11 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7VLkXIQ015746; Fri, 31 Aug 2007 14:46:33 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l7VLkoFn017870; Fri, 31 Aug 2007 14:48:03 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 14:48:02 -0700 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] Concepts draft Date: Fri, 31 Aug 2007 14:47:57 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE042@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts draft Thread-Index: AcfsFeXubqCZCtVAQ+av0JtwaGQYQwAAW56w References: From: "Henry Sinnreich" To: "Philip Matthews" , "P2PSIP Mailing List" X-OriginalArrivalTime: 31 Aug 2007 21:48:02.0212 (UTC) FILETIME=[9AB2AE40:01C7EC18] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 >So right now we envision only a minor update for the Vancouver meeting. >Comments? This is the right approach.=20 We may also want to think if the concepts and glossary should be (1) one and the same paper or (2) we may be better off (IMHO) with a separate glossary that includes SIP, but is not necessarily focused only on SIP alone. Just like the ICE terminology for example makes it clear that ICE works for more than SIP alone. As mentioned, organizations spending money to deploy a DHT are most likely to want to use it for a larger spectrum of applications than just SIP. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Friday, August 31, 2007 4:28 PM To: P2PSIP Mailing List Subject: [P2PSIP] Concepts draft The authors of the Concepts draft have been discussing how we might =20 advance this draft in preparation for the next IETF meeting. There has been some discussion on the list recently on additional =20 terms that might be added to the draft, and we are following this =20 discussion closely. Once this resolves, we will propose text to cover =20 this. There is also the question of whether the P2P layer should be =20 distinct from the SIP layer. In the Chicago meeting, there seemed to =20 be a strong feeling that this was the right way to do, so I would =20 like to official ask the chairs whether we can consider this a WG =20 decision. If so, then we will document this in the draft. However, none of this is pointing to a major revision. Most of the =20 questions that are currently listed in the draft, or that were listed =20 in the so-called "Joint Presentation" in Chicago remain unresolved. =20 In the opinion of the authors, the next major revision needs to wait =20 until the WG comes up with a clearer view of which way it wants to =20 go. In particular, the 6 proposals that were presented in Chicago =20 need time to mature and potentially merge before a clear consensus =20 emerges. So right now we envision only a minor update for the Vancouver meeting. 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 Fri Aug 31 17:55:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRESD-0001gr-Hu; Fri, 31 Aug 2007 17:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRESC-0001gg-9u for p2psip@ietf.org; Fri, 31 Aug 2007 17:55:00 -0400 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRESA-0003wf-Se for p2psip@ietf.org; Fri, 31 Aug 2007 17:55:00 -0400 Received: by nz-out-0506.google.com with SMTP id n1so678153nzf for ; Fri, 31 Aug 2007 14:54:58 -0700 (PDT) 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=F178juQndECKFNTSAqPiaQyGiagW0ApJNY2jXJlMWH5TQbIs/yDxAwqWPUBrsaSc4LAq5Rm5PlWGKPBoq0iRgle7ojFbxhAlGQOJVWfEdHczppr1TY94BPAvDtxDDpo5gR4wWtJzHB8jbs24Fwd9jHuMwcWZ9HE5/07JqI38VeI= 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=gKe357vt91/Q3yhzckhAgCJbHHjs0B+C2K/8TS/iGUETxHroUzJy5sKVrm06/50UmVNhkeNISWpFdSMX4QH+x60jt2CO9iLTVxX26h/5y5bJlBV/ivqhkRevkwCg03s8x7xnysU4lhLiH5OcgY1Q4XjMnk/Rh6pxKxcSV0D48xo= Received: by 10.65.151.6 with SMTP id d6mr4298671qbo.1188597298329; Fri, 31 Aug 2007 14:54:58 -0700 (PDT) Received: by 10.65.180.16 with HTTP; Fri, 31 Aug 2007 14:54:58 -0700 (PDT) Message-ID: <4d4304a00708311454n664fa887r15aa23d3b8a0c440@mail.gmail.com> Date: Fri, 31 Aug 2007 17:54:58 -0400 From: "David A. Bryan" To: "Henry Sinnreich" Subject: Re: [P2PSIP] Concepts draft In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE042@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <24CCCC428EFEA2469BF046DB3C7A8D223AE042@namail5.corp.adobe.com> X-Google-Sender-Auth: 7ff4531d19dca65b X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Philip Matthews , 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 We are chartered here only to work on P2PSIP, so we can't (in the WG) make a general P2P glossary. We have a concepts document that is a chartered working group item to document, among other things, terminology. Personally, I think since we have a chartered WG item for definitions (the concepts draft) already, that is the right place for this work, rather than a new item. There has been a great deal of work and definition that is already reflected there. David On 8/31/07, Henry Sinnreich wrote: > >So right now we envision only a minor update for the Vancouver meeting. > >Comments? > > This is the right approach. > > We may also want to think if the concepts and glossary should be (1) one > and the same paper or (2) we may be better off (IMHO) with a separate > glossary that includes SIP, but is not necessarily focused only on SIP > alone. > Just like the ICE terminology for example makes it clear that ICE works > for more than SIP alone. > > As mentioned, organizations spending money to deploy a DHT are most > likely to want to use it for a larger spectrum of applications than just > SIP. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Friday, August 31, 2007 4:28 PM > To: P2PSIP Mailing List > Subject: [P2PSIP] Concepts draft > > The authors of the Concepts draft have been discussing how we might > advance this draft in preparation for the next IETF meeting. > > There has been some discussion on the list recently on additional > terms that might be added to the draft, and we are following this > discussion closely. Once this resolves, we will propose text to cover > this. > > There is also the question of whether the P2P layer should be > distinct from the SIP layer. In the Chicago meeting, there seemed to > be a strong feeling that this was the right way to do, so I would > like to official ask the chairs whether we can consider this a WG > decision. If so, then we will document this in the draft. > > However, none of this is pointing to a major revision. Most of the > questions that are currently listed in the draft, or that were listed > in the so-called "Joint Presentation" in Chicago remain unresolved. > In the opinion of the authors, the next major revision needs to wait > until the WG comes up with a clearer view of which way it wants to > go. In particular, the 6 proposals that were presented in Chicago > need time to mature and potentially merge before a clear consensus > emerges. > > So right now we envision only a minor update for the Vancouver meeting. > > 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 > -- 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 Fri Aug 31 21:30:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRHp3-0001yz-Ao; Fri, 31 Aug 2007 21:30:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRHp2-0001yr-LS for p2psip@ietf.org; Fri, 31 Aug 2007 21:30:48 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRHp2-0000AX-6R for p2psip@ietf.org; Fri, 31 Aug 2007 21:30:48 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IRHp1-0005tb-0D; Fri, 31 Aug 2007 21:30:47 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE042@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D223AE042@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <443C56B0-86FA-41BE-884F-A0A1BD994D4B@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Concepts draft Date: Fri, 31 Aug 2007 21:30:47 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 31-Aug-07, at 17:47 , Henry Sinnreich wrote: > We may also want to think if the concepts and glossary should be > (1) one > and the same paper or (2) we may be better off (IMHO) with a separate > glossary that includes SIP, but is not necessarily focused only on SIP > alone. I don't understand why you want a separate glossary document, given that the Concepts document already has a glossary (= Terminology) section. Are you saying that draft-willis-p2psip-concepts was a poor starting point for the WG Concepts document? In my opinion, as both a co-author of the current document and as a WG participant, the WG Concepts document can define any terms we think are useful. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Aug 31 23:19:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRJVE-0005KM-0Q; Fri, 31 Aug 2007 23:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRJVC-0005KH-1w for p2psip@ietf.org; Fri, 31 Aug 2007 23:18:26 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRJVA-000196-9Y for p2psip@ietf.org; Fri, 31 Aug 2007 23:18:26 -0400 Received: from cnshgsbhs02.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id l813GuQS012322 for ; Sat, 1 Sep 2007 11:17:02 +0800 Received: from CNSHGSMBS03.ad4.ad.alcatel.com ([172.24.146.174]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sat, 1 Sep 2007 11:18:15 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [P2PSIP] Concepts draft Date: Sat, 1 Sep 2007 11:18:14 +0800 Message-ID: In-Reply-To: <443C56B0-86FA-41BE-884F-A0A1BD994D4B@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts draft Thread-Index: AcfsOHAuKhJ7J67yTiSBvCg/bwheigADAkNQ References: <24CCCC428EFEA246 9BF046DB3C7A8D223AE042@namail5.corp.adobe.com> <443C56B0-86FA-41BE-884F-A0A1BD994D4B@magma.ca> From: "HUANG Ping B" To: "P2PSIP Mailing List" X-OriginalArrivalTime: 01 Sep 2007 03:18:15.0394 (UTC) FILETIME=[BC465420:01C7EC46] X-imss-version: 2.047 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Newton had said that:"I succeed because I stand on the shoulder of Giants"(maybe), this tell us that, if we want success, just stand "on"( not parallelly) the shoulder.:)! so "WG Concepts document can define any terms we think are useful." is the best choice! -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Saturday, September 01, 2007 9:31 AM To: Henry Sinnreich Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Concepts draft On 31-Aug-07, at 17:47 , Henry Sinnreich wrote: > We may also want to think if the concepts and glossary should be > (1) one > and the same paper or (2) we may be better off (IMHO) with a separate=20 > glossary that includes SIP, but is not necessarily focused only on SIP > alone. I don't understand why you want a separate glossary document, given that the Concepts document already has a glossary (=3D Terminology) section. Are you saying that draft-willis-p2psip-concepts was a poor starting point for the WG Concepts document? In my opinion, as both a co-author of the current document and as a WG participant, the WG Concepts document can define any terms we think are useful. - 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