From lin.xiao@nsn.com Wed Jul 1 02:51:34 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064EF3A6934 for ; Wed, 1 Jul 2009 02:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 tagged_above=-999 required=5 tests=[AWL=-2.718, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoPElsh7hwN5 for ; Wed, 1 Jul 2009 02:51:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id E66A73A6861 for ; Wed, 1 Jul 2009 02:51:32 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n619pqF0029844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Jul 2009 11:51:52 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n619ppLw019499; Wed, 1 Jul 2009 11:51:52 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 11:51:51 +0200 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, 1 Jul 2009 17:51:27 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA47F87E0@CNBEEXC007.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft on enhanced client operation for RELOAD Thread-Index: Acn5xHdjXSCOJeAySHaET63vlRlGBwAaNsgw References: From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Narayanan, Vidya" , X-OriginalArrivalTime: 01 Jul 2009 09:51:51.0039 (UTC) FILETIME=[8EA688F0:01C9FA31] Subject: Re: [P2PSIP] New draft on enhanced client operation for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 09:51:34 -0000 Hi Vidya, It is really a good start to discuss the client mobility issues in RELOAD. Using DAP and OAP seems a good solution for clients that attached to arbitary peers. However, does eClient really need a specific bootstrapping different with that in RELOAD BASE?=20 IMO, a client does not need to claim itselft an eClient or not when joining in the overlay. A ordinary bootstrapping can work as if it is a normal client. The node ID is allocated by bootstrap server. This client can use the Node ID to set up connection with OAP and neighbours as normal overlay nodes do. If the bootstrap server used here has the ability to consider a little bit physical network topology, the allocated node ID, of cause, is quite close to its OAP. There should no problem to set up a direct connection between the client and OAP on the overlay at the begining. Only when the client found that it is impossible to directly connect to its OAP (most of time, it is due to the client moving out of the OAD's reachability), it'll select a DAP from its neighbours. This could keep your scheme more simpler and accordant with RELOAD BASE. Right? Best Regards, Lin -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of ext Narayanan, Vidya Sent: Wednesday, July 01, 2009 4:51 AM To: p2psip@ietf.org Subject: [P2PSIP] New draft on enhanced client operation for RELOAD Hi, We have submitted a draft on enhanced client operation for RELOAD. It supports the attachment of clients to arbitrary peers without needing application specific destination list population and it inherently provides support for client mobility. =20 The draft can be found at http://www.ietf.org/internet-drafts/draft-vidya-p2psip-eclients-00.txt. Comments welcome. =20 Thanks, Vidya _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Wed Jul 1 07:56:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1873A6F43 for ; Wed, 1 Jul 2009 07:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.522 X-Spam-Level: X-Spam-Status: No, score=-106.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUmpNhMixks9 for ; Wed, 1 Jul 2009 07:56:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2CFDB3A6F3F for ; Wed, 1 Jul 2009 07:56:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,324,1243814400"; d="scan'208";a="208217736" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2009 14:55:51 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n61EtoGc008804; Wed, 1 Jul 2009 07:55:50 -0700 Received: from [192.168.1.75] (sjc-vpn3-143.cisco.com [10.21.64.143]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n61Eto0D011519; Wed, 1 Jul 2009 14:55:50 GMT Message-Id: <0840C7F2-4E8E-427C-B60F-72385E1BA860@cisco.com> From: Cullen Jennings To: Song Haibin In-Reply-To: <006a01c9ea6a$6b2b69d0$0f0ca40a@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 07:55:50 -0700 References: <006a01c9ea6a$6b2b69d0$0f0ca40a@china.huawei.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=646; t=1246460150; x=1247324150; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Route=20Logging=20parameter |Sender:=20; bh=UNghuhzmr5y36IbTrUQ5nwmdhB98NJKLZFI3UTnyGVY=; b=BtrGdssxhF1YiZKAWCWfdSLosCaUCUB9x39rvGzfl8IBS3vhzdTcTNyzBE Y4b/E1RQwxZIpJL/MvNtw2Erlvbi/NTwgXMH3tkZmd0Df37ziyqQiujl1Wk6 OOQvfyWWm/; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Route Logging parameter X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:56:53 -0000 I agree - it makes sense to me to move uptime to the diagnostics draft. Cullen On Jun 11, 2009, at 24:58 , Song Haibin wrote: > Hi, > > Peer's Uptime has been listed as a parameter in the structure of > RouteLogEntry in section 5.3.2.3 of the base draft, since the > diagnostics of > the overlay network has been removed from the base base draft, I > suggest to > remove this parameter here. > > Thanks, > Haibin > Skype: alexsonghw > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From vidyan@qualcomm.com Wed Jul 1 12:00:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B4C28C55C for ; Wed, 1 Jul 2009 12:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVxu-DiiEReU for ; Wed, 1 Jul 2009 12:00:29 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id DC3023A6839 for ; Wed, 1 Jul 2009 12:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1246474842; x=1278010842; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Cullen=20Jennings=20,=20Song=20Haibi n=20|CC:=20"'P2PSIP=20WG'"=20|Date:=20Wed,=201=20Jul=202009=2012:00:38=20- 0700|Subject:=20RE:=20[P2PSIP]=20Route=20Logging=20parame ter|Thread-Topic:=20[P2PSIP]=20Route=20Logging=20paramete r|Thread-Index:=20Acn6XD1GiveY2zdAS9SMhL38YmB8KgAIeX0w |Message-ID:=20|References:=20<006a01c9ea6 a$6b2b69d0$0f0ca40a@china.huawei.com>=0D=0A=20<0840C7F2-4 E8E-427C-B60F-72385E1BA860@cisco.com>|In-Reply-To:=20<084 0C7F2-4E8E-427C-B60F-72385E1BA860@cisco.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5663"=3B=20a=3D"20158594"; bh=sa6qIB0wDNVO7oc0SwsPKTX+9HPRF9lFJNKud8GNuEg=; b=rmD3qu9p7e0EIU2Utn6IJzrcO3JyUJqrpmLcsJj0CJHyHEe22YVrSXUN UeCXE/GTQBmRDZ4tc0qeHmxZWeqbAQd50TOMXqWD7l1hD87EWYrK1X9uD 0bgkNCAkqWP0cDyLdIw9YvPAU2Tu4PwszwPDBZTtltHRWBxYMoU5NEVWG U=; X-IronPort-AV: E=McAfee;i="5300,2777,5663"; a="20158594" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2009 12:00:41 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n61J0f7w014885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Jul 2009 12:00:41 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n61J0eTL013091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Jul 2009 12:00:41 -0700 (PDT) Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 1 Jul 2009 12:00:40 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Wed, 1 Jul 2009 12:00:40 -0700 From: "Narayanan, Vidya" To: Cullen Jennings , Song Haibin Date: Wed, 1 Jul 2009 12:00:38 -0700 Thread-Topic: [P2PSIP] Route Logging parameter Thread-Index: Acn6XD1GiveY2zdAS9SMhL38YmB8KgAIeX0w Message-ID: References: <006a01c9ea6a$6b2b69d0$0f0ca40a@china.huawei.com> <0840C7F2-4E8E-427C-B60F-72385E1BA860@cisco.com> In-Reply-To: <0840C7F2-4E8E-427C-B60F-72385E1BA860@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Route Logging parameter X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:00:31 -0000 I'm not sure why route logging should even be in the base draft to begin wi= th. Can we get rid of this altogether and leave it to the diagnostics draf= t?=20 Vidya > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Wednesday, July 01, 2009 7:56 AM > To: Song Haibin > Cc: 'P2PSIP WG' > Subject: Re: [P2PSIP] Route Logging parameter >=20 >=20 > I agree - it makes sense to me to move uptime to the diagnostics draft. >=20 > Cullen >=20 > On Jun 11, 2009, at 24:58 , Song Haibin wrote: >=20 > > Hi, > > > > Peer's Uptime has been listed as a parameter in the structure of > > RouteLogEntry in section 5.3.2.3 of the base draft, since the > > diagnostics of > > the overlay network has been removed from the base base draft, I > > suggest to > > remove this parameter here. > > > > Thanks, > > Haibin > > Skype: alexsonghw > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From vidyan@qualcomm.com Wed Jul 1 12:13:28 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692F73A698B for ; Wed, 1 Jul 2009 12:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFl7TNNnpnv4 for ; Wed, 1 Jul 2009 12:13:27 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 3AAF33A6839 for ; Wed, 1 Jul 2009 12:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1246475629; x=1278011629; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Xiao,=20Lin=20(NSN=20-=20CN/Beijing)"=20,=0D=0A=20=20=20=20=20=20=20=20"p2psip@ietf.org"=0D =0A=09|Date:=20Wed,=201=20Jul=202009=201 2:13:42=20-0700|Subject:=20RE:=20[P2PSIP]=20New=20draft =20on=20enhanced=20client=20operation=20for=20RELOAD |Thread-Topic:=20[P2PSIP]=20New=20draft=20on=20enhanced =20client=20operation=20for=20RELOAD|Thread-Index:=20Acn5 xHdjXSCOJeAySHaET63vlRlGBwAaNsgwABQ7OhA=3D|Message-ID:=20 |References:=20=0D=0A=20<5D 84FDD8D5DC8646B9F73CF1EFD1BFA47F87E0@CNBEEXC007.nsn-intra .net>|In-Reply-To:=20<5D84FDD8D5DC8646B9F73CF1EFD1BFA47F8 7E0@CNBEEXC007.nsn-intra.net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5663"=3B=20a=3D"20176193"; bh=qcmTAtsPdGyjlkIVnHNxZtZ5Yv1ysfVWmhF8j8Su9po=; b=MseypyEgH3O1lb1rWLqVeVr5Fkv5a6gZBNLvVByYZMmefouLjrbbqITi mKRvxyMUssdESEzQ9RF1R+ZWENLxh7qgKpem9MIlHKHAjgs55fNP5dhqV kHNNsJyjYC0Ewk9yTRUQ2w1O0sI2vKGGzknH5jroCAdh6hiih4chEtlPB Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5663"; a="20176193" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2009 12:13:49 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n61JDmA4016397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Jul 2009 12:13:49 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n61JDiKa015817 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Jul 2009 12:13:48 -0700 (PDT) Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 1 Jul 2009 12:13:45 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Wed, 1 Jul 2009 12:13:45 -0700 From: "Narayanan, Vidya" To: "Xiao, Lin (NSN - CN/Beijing)" , "p2psip@ietf.org" Date: Wed, 1 Jul 2009 12:13:42 -0700 Thread-Topic: [P2PSIP] New draft on enhanced client operation for RELOAD Thread-Index: Acn5xHdjXSCOJeAySHaET63vlRlGBwAaNsgwABQ7OhA= Message-ID: References: <5D84FDD8D5DC8646B9F73CF1EFD1BFA47F87E0@CNBEEXC007.nsn-intra.net> In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA47F87E0@CNBEEXC007.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [P2PSIP] New draft on enhanced client operation for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:13:28 -0000 Hi Lin, Thanks for looking through the draft and sharing comments. The motivation = to attach to an arbitrary peer may not only be driven by inability to attac= h to the OAP due to NAT problems - a node may choose to attach to a DAP due= to proximity or even to use the same DAP to attach to multiple overlays, t= hereby providing significant power savings to a client. Of course, a node = may choose to first attach as a regular client at the OAP and then decide t= o find a DAP if conditions change as well - the draft does not preclude tha= t. But, in order to handle appropriate state at OAP and DAP and to set up = the connections, we will need support for indicating the DAP to the OAP. =20 Also, we want the enrollment server to assign node ids randomly to all node= s. A node need not have a strict rule about always participating as a clie= nt or a peer - a node may start out as a peer and then switch to a client r= ole later (say, when its battery is low).=20 At the moment, even regular client behavior is not documented in the base d= raft. I had sent the authors some text a while ago for this. I will also = forward that along to the mailing list for comments. =20 Thanks, Vidya=20 > -----Original Message----- > From: Xiao, Lin (NSN - CN/Beijing) [mailto:lin.xiao@nsn.com] > Sent: Wednesday, July 01, 2009 2:51 AM > To: Narayanan, Vidya; p2psip@ietf.org > Subject: RE: [P2PSIP] New draft on enhanced client operation for RELOAD >=20 > Hi Vidya, >=20 > It is really a good start to discuss the client mobility issues in > RELOAD. Using DAP and OAP seems a good solution for clients that > attached to arbitary peers. However, does eClient really need a > specific > bootstrapping different with that in RELOAD BASE? >=20 > IMO, a client does not need to claim itselft an eClient or not when > joining in the overlay. A ordinary bootstrapping can work as if it is a > normal client. The node ID is allocated by bootstrap server. This > client > can use the Node ID to set up connection with OAP and neighbours as > normal overlay nodes do. If the bootstrap server used here has the > ability to consider a little bit physical network topology, the > allocated node ID, of cause, is quite close to its OAP. There should > no > problem to set up a direct connection between the client and OAP on the > overlay at the begining. Only when the client found that it is > impossible to directly connect to its OAP (most of time, it is due to > the client moving out of the OAD's reachability), it'll select a DAP > from its neighbours. This could keep your scheme more simpler and > accordant with RELOAD BASE. Right? >=20 > Best Regards, > Lin >=20 >=20 > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf > Of ext Narayanan, Vidya > Sent: Wednesday, July 01, 2009 4:51 AM > To: p2psip@ietf.org > Subject: [P2PSIP] New draft on enhanced client operation for RELOAD >=20 > Hi, > We have submitted a draft on enhanced client operation for RELOAD. It > supports the attachment of clients to arbitrary peers without needing > application specific destination list population and it inherently > provides support for client mobility. >=20 > The draft can be found at > http://www.ietf.org/internet-drafts/draft-vidya-p2psip-eclients-00.txt. > Comments welcome. >=20 > Thanks, > Vidya > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From vidyan@qualcomm.com Wed Jul 1 12:17:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AECB3A67E4 for ; Wed, 1 Jul 2009 12:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvr2L0ysz7td for ; Wed, 1 Jul 2009 12:17:56 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id D939728C130 for ; Wed, 1 Jul 2009 12:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1246475898; x=1278011898; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"p2psip@ietf.org"=20|Date:=20Wed,=201 =20Jul=202009=2012:18:13=20-0700|Subject:=20Client=20oper ation=20in=20RELOAD|Thread-Topic:=20Client=20operation=20 in=20RELOAD|Thread-Index:=20Acn6gK3A2+lg4CfyRseVJJ+XHcOuP w=3D=3D|Message-ID:=20|Accept-Language:=20 en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5663"=3B=20a=3D"20159510"; bh=6cXYVusTzQoeuZIMrjUaVRh2n7aPMpqck/4Bo/m2t7w=; b=GBhL7anPbQbWygyHLMogUsm4YenGKBNfmnexeqG61xoxLkJ2oa+LieeB kNH2b3x/cDoCCCqC6JtCCsVs25gV3VVeBBM1wWp7I+qFUXdfMnEfSRxa5 6gy8SSIb9c+rXmMaWtJAscQSzmJrCscboJaTrLpaXbqQdqbLdH707wHq6 A=; X-IronPort-AV: E=McAfee;i="5300,2777,5663"; a="20159510" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2009 12:18:16 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n61JIGY6016848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Jul 2009 12:18:16 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n61JIF9M017900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 1 Jul 2009 12:18:16 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 1 Jul 2009 12:18:15 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 1 Jul 2009 12:18:15 -0700 From: "Narayanan, Vidya" To: "p2psip@ietf.org" Date: Wed, 1 Jul 2009 12:18:13 -0700 Thread-Topic: Client operation in RELOAD Thread-Index: Acn6gK3A2+lg4CfyRseVJJ+XHcOuPw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:17:57 -0000 The client operation in RELOAD is currently underspecified and cannot be im= plemented based on the spec. Here are the procedures that need to be speci= fied to support client behavior with attachment at the identity owner. For= attachment at any other arbitrary point, a lot more thought needs to be pu= t in to ensure support for mobility and stability of operation. My suggest= ion is that it is better left outside the scope of this draft and defined s= eparately. In this case, RELOAD will only support attachment at the identi= ty owner, which seems very reasonable. =20 Message changes necessary to support clients:=20 --------------------------------------------- We need to introduce a "Node Type" in the JOIN Request message that indicat= es that the joining node wishes to do so as a client. Also, Update messages= need to have a "case clients" and the "case full" needs to include client = information. =20 I suggest adding a section on clients - suggested text below:=20 Clients:=20 -------- Clients are nodes that may provide and receive services in an overlay witho= ut participating in overlay routing or incurring the same amount of mainten= ance overhead as the overlay peers. Clients are modeled as close to peers = as possible in terms of overlay functionality. In order to allow these nod= es to participate in the overlay without inherently being a routing member = of the overlay, some changes are required to the join process and the manne= r in which neighbor relationships are handled for such nodes. However, all= other procedures (e.g., data management using STORE, FETCH, etc.) are hand= led in exactly the same way as for any other peer in the overlay. =20 We denote the point of attachment of the Non-Routing Peer on to the overlay= as Overlay Attachment Point (OAP). The peer responsible for the node ID o= f the client provides the OAP functionality. This allows the integration o= f clients into the architecture with the least deviation from the peer. He= nce, any node that wishes to be a client finds the node that owns its ident= ity space and attaches to it. By definition, any node serving as a peer in= the overlay MUST provide the OAP functionality as well. The mode of using= a different node as the OAP may be allowed as an extension to this protoco= l - this can be done for availability or load balancing reasons, for instan= ce. =20 =20 Clients obtain overlay node identities just like peers do. Hence, the enro= llment server may be completely unaware of the distinction between a peer a= nd a client. By virtue of this, the enrollment procedure is identical for = peers and clients. The join procedure is somewhat simplified for a client = and the section below describes that process. All data management operatio= ns to/from a client are indistinguishable from those of a peer. =20 The main difference between a client and a peer is that a client only has a= single neighbor in the overlay, i.e., the OAP. The client routes all mess= ages through the OAP - i.e., it has a default route with the OAP as next ho= p that is used for all messages. The OAP has the client as a neighbor and = has it in its routing table. None of the nodes in the overlay except the O= AP are aware of the presence of the client. The messages to/from a client a= re natively routed on the overlay. All messages that are sent to the clien= t arrive at the OAP by regular overlay routing (since it owns the identity = space that includes that of the client). The OAP then looks up its routing= table to route the message to the client. =20 The OAP may make use of the presence of a client to offload some of its sto= rage responsibilities or to replicate data stored at it. This may be mutua= lly beneficial in some cases - e.g., the client may be limited in terms of = bandwidth and battery, while the OAP may be limited in memory. However, thi= s is out of scope for this document itself and any such storage sharing tha= t occurs between a client and OAP is not visible to the rest of the overlay= . Hence, any such thing must be managed out of band between the OAP and th= e client. =20 Client Bootstrap Process:=20 ------------------------- A client obtains a list of bootstrap peers from the enrollment server as an= y other node in the overlay. The client triggers the join process the same= way as a peer does. But, the process is a bit more abridged than for a no= rmal peer. It is described below:=20 1. Client connects to its chosen bootstrap node. The client MUST form a TL= S session with the bootstrap node, using the certificate or PSK required fo= r overlay membership. =20 2. The client sends a Join request message to its own Node-ID c, through t= he BP. The Join Request message indicates that the joining entity is a cli= ent (with Node Type being set to Client). This is routed to the admitting = peer (AP). The AP sends a response to the Join, after noting that it must = serve as the OAP. =20 3. The client also sends an Attach request message to c through the BP. T= his may be sent in parallel with the Join message. The AP sends an Attach = response, resulting in connection establishment between the client and AP. = At this point, the AP has the client included in its routing and connectio= n tables and the client has established a default route through the AP. Th= e join process is now complete. =20 The OAP MUST NOT send any Update messages to other peers in the overlay as = a result of a client joining the overlay. The OAP simply updates its routi= ng and connection tables with the client information. The client does the = same. The OAP may, however, follow up the join process with a series of ST= ORE request messages to transfer some data it stores to the client.=20 Impact of Churn on Clients:=20 ----------------------------=20 As the ownership of the overlay identity space changes, the clients may be = affected. For instance, if the OAP to which a client is attached leaves th= e overlay or fails, the client needs to find the appropriate OAP to attach = to. Also, when the identity ownership changes due to a new peer attaching = between the OAP and the client in the identity space, the client needs to u= se the new peer as its OAP. Essentially, the need to change OAP may arise= from one of the following three conditions:=20 * A new peer joined the overlay with an identity that lies between the iden= tities of a client and its OAP * The OAP of a client performs a graceful leave from the overlay * The OAP of a client abruptly leaves the overlay or fails These three cases are explained below.=20 Handling New Peers:=20 ------------------- Consider the case where a client (C1) is attached to an OAP (OAP1). A new = peer, P, attaches to the overlay, with an identity that falls between C1's = and OAP1's identity. P is now responsible for the identity that belongs to= C1 and hence needs to serve as the OAP to C1 (say, OAP2). When P complete= s its Join process, OAP1 detects that it no longer owns the identity corres= ponding to C1. OAP1 now sends an Update message to C1, indicating that it = has a new neighbor. The Update message provides information about P to C1.= Upon receiving the Update message, C1 sends a Join Request via OAP1 to P.= The difference between this JOIN process and the regular one is that C1 c= an perform this Join via OAP1 instead of finding a bootstrap peer to perfor= m the join through. Since P is part of the overlay and is OAP1's neighbor,= OAP1 can reach P directly, thereby greatly reducing the number of hops the= Join messages need to traverse. Once the new Join process completes, P ta= kes over as C1's OAP (OAP2). C1 may send a Leave Request to OAP1 subsequen= t to its attachment to OAP2 - this will trigger cleaning up of state corres= ponding to C1 at OAP1. =20 If OAP1 stored any of its data at C1, C1 must transfer that back to OAP1 be= fore joining again with OAP2. The mechanism to handle this is out of scope= of this specification. =20 When a change in the identity space ownership causes the OAP of a particula= r node to change, the present OAP MUST send an Update message to the client= , indicating that it has a new neighbor. Upon receiving the update message= , the client MUST send a Join message to the new OAP - this JOIN message ca= n be routed through its current OAP. The client SHOULD send a Leave reques= t to its old OAP, once it has successfully attached to the new OAP. =20 Graceful Leave of an OAP: ------------------------- When an OAP gracefully leaves an overlay, it typically sends a LEAVE reques= t message to all its neighbors. In addition, the OAP SHOULD send a Leave R= equest message to the client. Further, the OAP SHOULD also send an Update = message to the client, containing information about its successor, which wi= ll be the new OAP for the client. When the client receives such an Update = Request, it MUST send a Join Request message to its new OAP. If the old OA= P is able to assist in the Join process, the Join messages can traverse thr= ough it to set up the connection between the client and its new OAP. Howev= er, if the old OAP leaves the overlay prior to that process, the client nee= ds to find a bootstrap peer and route its Join Request message through that= peer to its new OAP, in which case, the procedure becomes similar to the f= ailure of an OAP case described below. =20 Failure of an OAP:=20 ------------------ An abrupt leave or a failure of an OAP implies that there is no active mess= aging from the OAP to its clients indicating that an OAP change is required= . In this case, the client will detect the absence of its OAP due to a tim= eout indicating that the OAP is unreachable. The client then needs to perf= orm the Join process via a bootstrap peer in the overlay to find its new OA= P. =20 =20 Impact on attach messages:=20 --------------------------- There is an issue that nodes may send attach messages to the client's node = id when looking for a finger. The client needs to reject such Attach reque= sts coming to it. However, the client will be unable to distinguish Attach= messages that are being sent to it to really set up an end-to-end connecti= on for other purposes. We may want to consider introducing a "purpose" in = the Attach request messages that indicate the reason for the Attach. This = will make it possible for the client to reject a request that is sent to es= tablish a finger. The node sending the Attach request can then slightly al= ter the resource id to issue another request. =20 Thanks, Vidya From davidbryan@gmail.com Wed Jul 1 18:41:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB913A6897 for ; Wed, 1 Jul 2009 18:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6vwLO9akGfG for ; Wed, 1 Jul 2009 18:41:43 -0700 (PDT) Received: from mail-vw0-f184.google.com (mail-vw0-f184.google.com [209.85.212.184]) by core3.amsl.com (Postfix) with ESMTP id 6AE623A6840 for ; Wed, 1 Jul 2009 18:41:43 -0700 (PDT) Received: by vwj14 with SMTP id 14so681377vwj.29 for ; Wed, 01 Jul 2009 18:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OFXB/Y+fAorwxs03QuIPtmgKMig+9nexbKsErOd7Ipk=; b=v+e4dotVNZDNbUyFjZ8eYg/KELt+9dZ/YZABgQeqmWEn0oU9XtngXOw+zvsTdWJoPf zqnNZvaFRb/laHZdtNEpn/p5mQMuWa3V2lqTzwVHyXmVqLCHYLCV52zNbAJ85Zxw6AZ9 fH8klG+qP3NQ0YkFB6dSxHrCxBXSEWndb4Mys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=neSYJ0PN+U+b09n+IrdH0H7HVsWT/bVQeYn/3WnAQhKtpIZpVvudmpmIDC04QPstul OHcYPEV0KIjxYBeAjuhygb/zZwbDWETurKvnfyl13+UuC/7KsUc8pWljQ97GnNZ6EO5j VhexkEKldVqZYb4AhLBGmZs9fNDtvdn/dBRDI= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.220.85.81 with SMTP id n17mr10286727vcl.54.1246498922195; Wed, 01 Jul 2009 18:42:02 -0700 (PDT) Date: Wed, 1 Jul 2009 21:42:02 -0400 X-Google-Sender-Auth: 37be09ab2aba06c1 Message-ID: <8b2769930907011842n300797afmeb2459910ff5be5c@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Agenda Requests X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 01:41:44 -0000 Please send Brian and I your agenda requests. As usual, list discussion is a must for non-WG items. I'd also like to ask everyone to read and comment on the drafts that have been submitted in the last few days. Thanks, David From melodysong@huawei.com Wed Jul 1 18:44:13 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4E0B3A6B70 for ; Wed, 1 Jul 2009 18:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubt5Ea3VLHOW for ; Wed, 1 Jul 2009 18:44:12 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BB74C3A6897 for ; Wed, 1 Jul 2009 18:44:12 -0700 (PDT) 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 <0KM400L82SU09C@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 02 Jul 2009 09:44:24 +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 <0KM400JWLSU0JU@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 02 Jul 2009 09:44:24 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM400CC6STZR2@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 02 Jul 2009 09:44:24 +0800 (CST) Date: Thu, 02 Jul 2009 09:44:27 +0800 From: Song Haibin In-reply-to: To: "'Narayanan, Vidya'" , 'Cullen Jennings' Message-id: <006601c9fab6$a2a05c20$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acn6XD1GiveY2zdAS9SMhL38YmB8KgAIeX0wAA1OAEA= Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Route Logging parameter X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 01:44:13 -0000 Um... It seems that we should move the route logging to the daignostics draft if it is not binded to the normal messages that are not diagnostics. I was wondering if we can integrate the route logging with the Inspect message. There were comments to route log in the mailing list which will help to fix it better. Another issue is, as the definiton for some kind of diagnostics information has been transferred to the diagnostics draft, shall we also move the data kind registry for these diagnostics information (in section 13.4 of the base draft) there? Thanks! Haibin >-----Original Message----- >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >Sent: Thursday, July 02, 2009 3:01 AM >To: Cullen Jennings; Song Haibin >Cc: 'P2PSIP WG' >Subject: RE: [P2PSIP] Route Logging parameter > >I'm not sure why route logging should even be in the base >draft to begin with. Can we get rid of this altogether and >leave it to the diagnostics draft? > >Vidya > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> Behalf Of Cullen Jennings >> Sent: Wednesday, July 01, 2009 7:56 AM >> To: Song Haibin >> Cc: 'P2PSIP WG' >> Subject: Re: [P2PSIP] Route Logging parameter >> >> >> I agree - it makes sense to me to move uptime to the >diagnostics draft. >> >> Cullen >> >> On Jun 11, 2009, at 24:58 , Song Haibin wrote: >> >> > Hi, >> > >> > Peer's Uptime has been listed as a parameter in the structure of >> > RouteLogEntry in section 5.3.2.3 of the base draft, since the >> > diagnostics of the overlay network has been removed from the base >> > base draft, I suggest to remove this parameter here. >> > >> > Thanks, >> > Haibin >> > Skype: alexsonghw >> > >> > >> > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From bbl@lowekamp.net Wed Jul 1 19:15:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239AD3A68AF for ; Wed, 1 Jul 2009 19:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwrI+oF0Mh5C for ; Wed, 1 Jul 2009 19:15:15 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 161843A67A3 for ; Wed, 1 Jul 2009 19:15:14 -0700 (PDT) Received: by fxm18 with SMTP id 18so1190842fxm.37 for ; Wed, 01 Jul 2009 19:15:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.1 with SMTP id a1mr6711265fas.52.1246500929413; Wed, 01 Jul 2009 19:15:29 -0700 (PDT) In-Reply-To: <006601c9fab6$a2a05c20$0f0ca40a@china.huawei.com> References: <006601c9fab6$a2a05c20$0f0ca40a@china.huawei.com> Date: Wed, 1 Jul 2009 22:15:29 -0400 Message-ID: From: Bruce Lowekamp To: Song Haibin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Route Logging parameter X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 02:15:16 -0000 Route logging is going to be removed entirely from the next base draft update, due to the problems it causes with fragmentation and message length. I apologize that we never got an interim update out this cycle with that in it, but that was one of the non-controversial changes that was in the lengthy thread on congestion/fragmentation/etc that was started soon after the last meeting. Bruce On Wed, Jul 1, 2009 at 9:44 PM, Song Haibin wrote: > Um... It seems that we should move the route logging to the daignostics > draft if it is not binded to the normal messages that are not diagnostics= . I > was wondering if we can integrate the route logging with the Inspect > message. There were comments to route log in the mailing list which will > help to fix it better. > > Another issue is, as the definiton for some kind of diagnostics informati= on > has been transferred to the diagnostics draft, shall we also move the dat= a > kind registry for these diagnostics information (in section 13.4 of the b= ase > draft) there? > > Thanks! > Haibin > > > >>-----Original Message----- >>From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>Sent: Thursday, July 02, 2009 3:01 AM >>To: Cullen Jennings; Song Haibin >>Cc: 'P2PSIP WG' >>Subject: RE: [P2PSIP] Route Logging parameter >> >>I'm not sure why route logging should even be in the base >>draft to begin with. =C2=A0Can we get rid of this altogether and >>leave it to the diagnostics draft? >> >>Vidya >> >>> -----Original Message----- >>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>> Behalf Of Cullen Jennings >>> Sent: Wednesday, July 01, 2009 7:56 AM >>> To: Song Haibin >>> Cc: 'P2PSIP WG' >>> Subject: Re: [P2PSIP] Route Logging parameter >>> >>> >>> I agree - it makes sense to me to move uptime to the >>diagnostics draft. >>> >>> Cullen >>> >>> On Jun 11, 2009, at 24:58 , Song Haibin wrote: >>> >>> > Hi, >>> > >>> > Peer's Uptime has been listed as a parameter in the structure of >>> > RouteLogEntry in section 5.3.2.3 of the base draft, since the >>> > diagnostics of the overlay network has been removed from the base >>> > base draft, I suggest to remove this parameter here. >>> > >>> > Thanks, >>> > Haibin >>> > Skype: alexsonghw >>> > >>> > >>> > >>> > _______________________________________________ >>> > P2PSIP mailing list >>> > P2PSIP@ietf.org >>> > https://www.ietf.org/mailman/listinfo/p2psip >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From lin.xiao@nsn.com Wed Jul 1 20:42:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A803A68F5 for ; Wed, 1 Jul 2009 20:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.864 X-Spam-Level: X-Spam-Status: No, score=-4.864 tagged_above=-999 required=5 tests=[AWL=-2.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwc2RWdAKeMK for ; Wed, 1 Jul 2009 20:42:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 105473A68C5 for ; Wed, 1 Jul 2009 20:42:28 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n623gm9F004733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Jul 2009 05:42:48 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n623gmf8007004; Thu, 2 Jul 2009 05:42:48 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 05:42:47 +0200 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: Thu, 2 Jul 2009 11:42:37 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4822337@CNBEEXC007.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Client operation in RELOAD Thread-Index: Acn6gK3A2+lg4CfyRseVJJ+XHcOuPwAPYOaw References: From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Narayanan, Vidya" , X-OriginalArrivalTime: 02 Jul 2009 03:42:47.0853 (UTC) FILETIME=[2AB23DD0:01C9FAC7] Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 03:42:31 -0000 Hi vidyan, I also agree with you to give a deeper discussion and specification on RELOAD clients. IMO, all client related specification could be taken out side of BASE draft. RELOAD BASE just need give a general rule for overlay construction and common behavior of both peers and clients.=20 In your email below, you defined clients as nodes without routing responsibility. However, in RELOAD Base, clients was defined as nodes which have Node-ID but do not participate in routing or storage. That means, They could be nodes with routing but without storage. Three kinds of clients has been analysed in draft [draft-xiao-p2psip-client-routing-00.txt], http://www.ietf.org/internet-drafts/draft-xiao-p2psip-client-routing-00. txt. This small difference may need to be negotiate with RELOAD Base. No matter what the result will be, at least, we should discuss something basing on a same terminology, right? You recommend only a single neighbour for each client. IMO, a client can maintain more than one neighbours, but only keeps one entry in its Routing Table at a time. It not only ensures all messages from/to the client are through the OAP, but also make sure the client could be quickly hand over to a Direct Attachment Point (DAP), which can be selected directly from the neighbours, when necessary. It offers a seamless transfer from client to eclient. By the way. in my draft [draft-xiao-p2psip-client-routing-00.txt], the Routing Client and Pure Client defined there are in the scope of your client discussion with similar concern. We do need a unified protocol for Reload clients. Best Regards Lin -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of ext Narayanan, Vidya Sent: Thursday, July 02, 2009 3:18 AM To: p2psip@ietf.org Subject: [P2PSIP] Client operation in RELOAD The client operation in RELOAD is currently underspecified and cannot be implemented based on the spec. Here are the procedures that need to be specified to support client behavior with attachment at the identity owner. For attachment at any other arbitrary point, a lot more thought needs to be put in to ensure support for mobility and stability of operation. My suggestion is that it is better left outside the scope of this draft and defined separately. In this case, RELOAD will only support attachment at the identity owner, which seems very reasonable. =20 Message changes necessary to support clients:=20 --------------------------------------------- We need to introduce a "Node Type" in the JOIN Request message that indicates that the joining node wishes to do so as a client. Also, Update messages need to have a "case clients" and the "case full" needs to include client information. =20 I suggest adding a section on clients - suggested text below:=20 Clients:=20 -------- Clients are nodes that may provide and receive services in an overlay without participating in overlay routing or incurring the same amount of maintenance overhead as the overlay peers. Clients are modeled as close to peers as possible in terms of overlay functionality. In order to allow these nodes to participate in the overlay without inherently being a routing member of the overlay, some changes are required to the join process and the manner in which neighbor relationships are handled for such nodes. However, all other procedures (e.g., data management using STORE, FETCH, etc.) are handled in exactly the same way as for any other peer in the overlay. =20 We denote the point of attachment of the Non-Routing Peer on to the overlay as Overlay Attachment Point (OAP). The peer responsible for the node ID of the client provides the OAP functionality. This allows the integration of clients into the architecture with the least deviation from the peer. Hence, any node that wishes to be a client finds the node that owns its identity space and attaches to it. By definition, any node serving as a peer in the overlay MUST provide the OAP functionality as well. The mode of using a different node as the OAP may be allowed as an extension to this protocol - this can be done for availability or load balancing reasons, for instance. =20 =20 Clients obtain overlay node identities just like peers do. Hence, the enrollment server may be completely unaware of the distinction between a peer and a client. By virtue of this, the enrollment procedure is identical for peers and clients. The join procedure is somewhat simplified for a client and the section below describes that process. All data management operations to/from a client are indistinguishable from those of a peer. =20 The main difference between a client and a peer is that a client only has a single neighbor in the overlay, i.e., the OAP. The client routes all messages through the OAP - i.e., it has a default route with the OAP as next hop that is used for all messages. The OAP has the client as a neighbor and has it in its routing table. None of the nodes in the overlay except the OAP are aware of the presence of the client. The messages to/from a client are natively routed on the overlay. All messages that are sent to the client arrive at the OAP by regular overlay routing (since it owns the identity space that includes that of the client). The OAP then looks up its routing table to route the message to the client. =20 The OAP may make use of the presence of a client to offload some of its storage responsibilities or to replicate data stored at it. This may be mutually beneficial in some cases - e.g., the client may be limited in terms of bandwidth and battery, while the OAP may be limited in memory. However, this is out of scope for this document itself and any such storage sharing that occurs between a client and OAP is not visible to the rest of the overlay. Hence, any such thing must be managed out of band between the OAP and the client. =20 Client Bootstrap Process:=20 ------------------------- A client obtains a list of bootstrap peers from the enrollment server as any other node in the overlay. The client triggers the join process the same way as a peer does. But, the process is a bit more abridged than for a normal peer. It is described below:=20 1. Client connects to its chosen bootstrap node. The client MUST form a TLS session with the bootstrap node, using the certificate or PSK required for overlay membership. =20 2. The client sends a Join request message to its own Node-ID c, through the BP. The Join Request message indicates that the joining entity is a client (with Node Type being set to Client). This is routed to the admitting peer (AP). The AP sends a response to the Join, after noting that it must serve as the OAP. =20 3. The client also sends an Attach request message to c through the BP. This may be sent in parallel with the Join message. The AP sends an Attach response, resulting in connection establishment between the client and AP. At this point, the AP has the client included in its routing and connection tables and the client has established a default route through the AP. The join process is now complete. =20 The OAP MUST NOT send any Update messages to other peers in the overlay as a result of a client joining the overlay. The OAP simply updates its routing and connection tables with the client information. The client does the same. The OAP may, however, follow up the join process with a series of STORE request messages to transfer some data it stores to the client.=20 Impact of Churn on Clients:=20 ----------------------------=20 As the ownership of the overlay identity space changes, the clients may be affected. For instance, if the OAP to which a client is attached leaves the overlay or fails, the client needs to find the appropriate OAP to attach to. Also, when the identity ownership changes due to a new peer attaching between the OAP and the client in the identity space, the client needs to use the new peer as its OAP. Essentially, the need to change OAP may arise from one of the following three conditions:=20 * A new peer joined the overlay with an identity that lies between the identities of a client and its OAP * The OAP of a client performs a graceful leave from the overlay * The OAP of a client abruptly leaves the overlay or fails These three cases are explained below.=20 Handling New Peers:=20 ------------------- Consider the case where a client (C1) is attached to an OAP (OAP1). A new peer, P, attaches to the overlay, with an identity that falls between C1's and OAP1's identity. P is now responsible for the identity that belongs to C1 and hence needs to serve as the OAP to C1 (say, OAP2). When P completes its Join process, OAP1 detects that it no longer owns the identity corresponding to C1. OAP1 now sends an Update message to C1, indicating that it has a new neighbor. The Update message provides information about P to C1. Upon receiving the Update message, C1 sends a Join Request via OAP1 to P. The difference between this JOIN process and the regular one is that C1 can perform this Join via OAP1 instead of finding a bootstrap peer to perform the join through. Since P is part of the overlay and is OAP1's neighbor, OAP1 can reach P directly, thereby greatly reducing the number of hops the Join messages need to traverse. Once the new Join process completes, P takes over as C1' s OAP (OAP2). C1 may send a Leave Request to OAP1 subsequent to its attachment to OAP2 - this will trigger cleaning up of state corresponding to C1 at OAP1. =20 If OAP1 stored any of its data at C1, C1 must transfer that back to OAP1 before joining again with OAP2. The mechanism to handle this is out of scope of this specification. =20 When a change in the identity space ownership causes the OAP of a particular node to change, the present OAP MUST send an Update message to the client, indicating that it has a new neighbor. Upon receiving the update message, the client MUST send a Join message to the new OAP - this JOIN message can be routed through its current OAP. The client SHOULD send a Leave request to its old OAP, once it has successfully attached to the new OAP. =20 Graceful Leave of an OAP: ------------------------- When an OAP gracefully leaves an overlay, it typically sends a LEAVE request message to all its neighbors. In addition, the OAP SHOULD send a Leave Request message to the client. Further, the OAP SHOULD also send an Update message to the client, containing information about its successor, which will be the new OAP for the client. When the client receives such an Update Request, it MUST send a Join Request message to its new OAP. If the old OAP is able to assist in the Join process, the Join messages can traverse through it to set up the connection between the client and its new OAP. However, if the old OAP leaves the overlay prior to that process, the client needs to find a bootstrap peer and route its Join Request message through that peer to its new OAP, in which case, the procedure becomes similar to the failure of an OAP case described below. =20 Failure of an OAP:=20 ------------------ An abrupt leave or a failure of an OAP implies that there is no active messaging from the OAP to its clients indicating that an OAP change is required. In this case, the client will detect the absence of its OAP due to a timeout indicating that the OAP is unreachable. The client then needs to perform the Join process via a bootstrap peer in the overlay to find its new OAP. =20 =20 Impact on attach messages:=20 --------------------------- There is an issue that nodes may send attach messages to the client's node id when looking for a finger. The client needs to reject such Attach requests coming to it. However, the client will be unable to distinguish Attach messages that are being sent to it to really set up an end-to-end connection for other purposes. We may want to consider introducing a "purpose" in the Attach request messages that indicate the reason for the Attach. This will make it possible for the client to reject a request that is sent to establish a finger. The node sending the Attach request can then slightly alter the resource id to issue another request. =20 Thanks, Vidya _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From ekr@networkresonance.com Wed Jul 1 20:57:04 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867EC3A68F5 for ; Wed, 1 Jul 2009 20:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.27 X-Spam-Level: X-Spam-Status: No, score=-0.27 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdzmDayrzne0 for ; Wed, 1 Jul 2009 20:57:03 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id CC53A3A6C9A for ; Wed, 1 Jul 2009 20:55:30 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D4CD91C61F6; Wed, 1 Jul 2009 20:56:08 -0700 (PDT) Date: Wed, 01 Jul 2009 20:56:08 -0700 From: Eric Rescorla To: Song Haibin In-Reply-To: <00a001c9fa02$adfae770$0f0ca40a@china.huawei.com> References: <20090701031556.DDA881C6057@kilo.networkresonance.com> <00a001c9fa02$adfae770$0f0ca40a@china.huawei.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090702035608.D4CD91C61F6@kilo.networkresonance.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] P2PSIP Security Requirements Taken Out From draft-matuszewski-p2psip-security-requirements-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 03:57:04 -0000 At Wed, 01 Jul 2009 12:16:12 +0800, Song Haibin wrote: > >I actually think this is a bad idea. Previous experiences with > >trying to design access control systems (see WebDAV ACLs) have > >turned out to be really overcomplicated. As far as I can tell, > >this isn't necessary for the SIP use cases. > > > > As RELOAD is designed to support various usages. Other usages may have this > requirement. For example, we can image group communication scenarios, only > members of a group can retrieve and modify the files belonging to this > group. I think ACL might work. Sure. I'm not saying that one couldn't do an ACL extension to RELOAD at some point in the future to support some future usages. My point is that we don't need it for the current set of applications. > Could you tell me what causes the WebDAV ACLs > overcomplicated? That people want to be able to specify complicated policies, so once you open the door to ACLs it gets complicated. And of course the situation here is inherently more complicated since you're asking people you basically don't trust to enforce access control for you. > >> Req. 12: It SHOULD be possible to limit the impact of badly behaving > >> P2PSIP nodes on the overall system security. There SHOULD be an > >> option to identify malfunctioning or badly behaving nodes, > >and exclude > >> or reject them from the P2PSIP system. > > > >Hmm... It seems to me that this is already possible at least > >in some sense: you use short-lived certificates and then > >refuse to reissue their certificates. Did you have something > >else in mind? CRLs? > > > I'm not sure about the solution here. I think it may be hard to determine > the TTL for such kind shor-lived certificates. Misbehaving nodes still > function in the overlay until its certificate expires. Too short TTL may > overload the CA anyway. I don't know how CRLs work in the overlay, in a p2p > fashion or in a c/s fashion. Me neither. And since overlays are resistant to a certain amount of misbehavior, I don't know if we need to solve this right now. -Ekr From meng.yu@zte.com.cn Wed Jul 1 23:31:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1349E3A68EB for ; Wed, 1 Jul 2009 23:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvCEKnaZa+lq for ; Wed, 1 Jul 2009 23:31:26 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id AC3323A687C for ; Wed, 1 Jul 2009 23:31:25 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91102075036648; Thu, 2 Jul 2009 14:19:37 +0800 (CST) Received: from [10.30.1.239] by [10.30.17.100] with StormMail ESMTP id 53123.2075036648; Thu, 2 Jul 2009 14:23:39 +0800 (CST) From: meng.yu@zte.com.cn To: "p2psip@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: Sender: meng.yu@zte.com.cn Date: Thu, 2 Jul 2009 14:20:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-02 14:30:03, Serialize complete at 2009-07-02 14:30:03 Content-Type: multipart/alternative; boundary="=_alternative 0022CCFD482575E7_=" Subject: [P2PSIP] New version for draft "P2PSIP Event Notification Extension" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 06:31:27 -0000 This is a multipart message in MIME format. --=_alternative 0022CCFD482575E7_= Content-Type: text/plain; charset="US-ASCII" Hi, We have submitted the new version 01 for draft "P2PSIP Event Notification Extension". Through the extension for reload, it provides the mechanism that the resource data update could be informed to the application using this resource immediately. The applications maybe running in different nodes other than the resource responding peer. This mechanism will be helpful for the realtime applications based on p2p overlay. This draft can be found in the following link: https://datatracker.ietf.org/drafts/draft-wang-p2psip-event-notification-extension/ Welcome comments. Best Regards, Meng Yu ================== ZTE Corporation --=_alternative 0022CCFD482575E7_= Content-Type: text/html; charset="US-ASCII"
Hi,
We have submitted the new version 01 for draft "P2PSIP Event Notification Extension". Through the extension for reload, it provides the mechanism that the resource data update could be informed to the application using this resource immediately. The applications maybe running in different nodes other than the resource responding peer.
This mechanism will be helpful for the realtime applications based on p2p overlay.

This draft can be found in the following link:
https://datatracker.ietf.org/drafts/draft-wang-p2psip-event-notification-extension/

Welcome comments.

Best Regards,

Meng Yu
==================
ZTE Corporation
 --=_alternative 0022CCFD482575E7_=-- From shen.jiong@zte.com.cn Thu Jul 2 00:05:33 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7F83A6A43 for ; Thu, 2 Jul 2009 00:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.415 X-Spam-Level: X-Spam-Status: No, score=-99.415 tagged_above=-999 required=5 tests=[AWL=-2.423, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3UvW2cRBZhi for ; Thu, 2 Jul 2009 00:05:32 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CB56B3A68B0 for ; Thu, 2 Jul 2009 00:05:31 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91102075036648; Thu, 2 Jul 2009 14:53:05 +0800 (CST) Received: from [10.30.1.239] by [10.30.17.99] with StormMail ESMTP id 56181.2075036648; Thu, 2 Jul 2009 14:58:51 +0800 (CST) In-Reply-To: To: "p2psip@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: shen.jiong@zte.com.cn Date: Thu, 2 Jul 2009 15:05:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-02 15:05:49, Serialize complete at 2009-07-02 15:05:49 Content-Type: multipart/alternative; boundary="=_alternative 0026BED9482575E7_=" Subject: [P2PSIP] =?gb2312?b?tPC4tDogIE5ldyBkcmFmdCBvbiBjb250ZW50IHNoYXJp?= =?gb2312?b?bmcgdXNhZ2UgZm9yIFJFTE9BRA==?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 07:05:33 -0000 This is a multipart message in MIME format. --=_alternative 0026BED9482575E7_= Content-Type: text/plain; charset="US-ASCII" Hi all, We have submitted a draft on content sharing usage for RELOAD. It provides the functionality of distributing and fetching shared content efficiently to and from a P2P overlay network, which performs as Content Delivery Network and is service insensitive. The draft can be found at http://www.ietf.org/internet-drafts/draft-shen-p2psip-content-sharing-00.txt . Comments are welcome. Thanks, Jiong P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0026BED9482575E7_= Content-Type: text/html; charset="US-ASCII"


Hi all,

We have submitted a draft on content sharing usage for RELOAD. It provides the functionality of distributing and fetching shared content efficiently to and from a P2P overlay network, which performs as Content Delivery Network and is service insensitive.

The draft can be found at http://www.ietf.org/internet-drafts/draft-shen-p2psip-content-sharing-00.txt.  Comments are welcome.


Thanks,
Jiong

P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0026BED9482575E7_=-- From abcdmatao@gmail.com Thu Jul 2 01:54:05 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90383A69EA for ; Thu, 2 Jul 2009 01:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVl2YMH0eQsa for ; Thu, 2 Jul 2009 01:54:05 -0700 (PDT) Received: from mail-qy0-f196.google.com (mail-qy0-f196.google.com [209.85.221.196]) by core3.amsl.com (Postfix) with ESMTP id 878693A69B1 for ; Thu, 2 Jul 2009 01:53:59 -0700 (PDT) Received: by qyk34 with SMTP id 34so870328qyk.29 for ; Thu, 02 Jul 2009 01:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=3Js/i8+Bk1IusXy6qIAqDU+b7ykZhFmv+SLoMnZhAaQ=; b=P/up/vRzbKY1gqeekVtfH9AKjwzaWWO2MfmsslVeX3lb8a4gw8wfmyYCymvQBRW5s6 aVfK1DyRhj9VK6P0Ejij8Yy4qaGUY2VndH+vxJPS4UpBpYWgWQ0+xRybNKIhvgVu1Kz+ CDnkuASCRca9vJZxBYyYspPCDyHi3yMiRN674= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Soz9x8c9lawNeQ9U1OxkrhP5IukbL96gnu5ljd4WqcyJscGm7GzFd1aNrNb2P1KGCD WLnz5nABP6Vj/RU29TNGbsWm9s/PL3f9qRSrKKmuAKHa6rtV9uwTivIGP20X9rafexLf 1xq2YJF06rkiHU/Axpp1eS2qYwamD/eITNEOQ= MIME-Version: 1.0 Received: by 10.224.28.145 with SMTP id m17mr6919300qac.214.1246524859061; Thu, 02 Jul 2009 01:54:19 -0700 (PDT) Date: Thu, 2 Jul 2009 16:54:18 +0800 Message-ID: <99978d7d0907020154q7518694kd82f54c03ed3615a@mail.gmail.com> From: Tao Ma To: meng.yu@zte.com.cn, p2psip@ietf.org Content-Type: multipart/alternative; boundary=0015175ce07a6d98fb046db52fcf Cc: standardMINE@googlegroups.com Subject: Re: [P2PSIP] New version for draft "P2PSIP Event Notification Extension" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 08:54:05 -0000 --0015175ce07a6d98fb046db52fcf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Meng, I don't really understand the scenario of real time data synchronization. Could you explain it more detailed by some examples? Besides, the 3.2.2 mentioned subscription events. What does the event mean? What kind of events does a subscriber need to know? Best Regards Tao Ma 2,July,2009 Beijing University of Posts and Telecommunications, Mobile life and new media lab --0015175ce07a6d98fb046db52fcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Meng,
=A0=A0=A0 I don't really understand the scenario of real = time data synchronization. Could you explain it more detailed by some examp= les? Besides, the 3.2.2 mentioned subscription events. What does the event = mean? What kind of events does a subscriber need to know?
=A0 Best Regards
Tao Ma
2,July,2009
Beijing = University of Posts and Telecommunications, Mobile life and new media lab

--0015175ce07a6d98fb046db52fcf-- From melodysong@huawei.com Thu Jul 2 02:25:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81D128C165 for ; Thu, 2 Jul 2009 02:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVwyciJKKqjE for ; Thu, 2 Jul 2009 02:25:35 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D209F28C1A7 for ; Thu, 2 Jul 2009 02:25:34 -0700 (PDT) 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 <0KM5005EDE3M3G@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 02 Jul 2009 17:23:46 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM500DSME3M81@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 02 Jul 2009 17:23:46 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM500MWVE3LDJ@szxml06-in.huawei.com> for p2psip@ietf.org; Thu, 02 Jul 2009 17:23:46 +0800 (CST) Date: Thu, 02 Jul 2009 17:23:45 +0800 From: Song Haibin In-reply-to: <20090702035608.D4CD91C61F6@kilo.networkresonance.com> To: 'Eric Rescorla' Message-id: <003701c9faf6$ccb829d0$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acn6ySmYY0E9cAF2RRuCdsjm9qRDpAALByaA Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] P2PSIP Security Requirements Taken Out From draft-matuszewski-p2psip-security-requirements-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 09:25:35 -0000 > >At Wed, 01 Jul 2009 12:16:12 +0800, >Song Haibin wrote: >> >I actually think this is a bad idea. Previous experiences >with trying >> >to design access control systems (see WebDAV ACLs) have >turned out to >> >be really overcomplicated. As far as I can tell, this isn't >necessary >> >for the SIP use cases. >> > >> >> As RELOAD is designed to support various usages. Other >usages may have >> this requirement. For example, we can image group communication >> scenarios, only members of a group can retrieve and modify the files >> belonging to this group. I think ACL might work. > >Sure. I'm not saying that one couldn't do an ACL extension to >RELOAD at some point in the future to support some future >usages. My point is that we don't need it for the current set >of applications. > > >> Could you tell me what causes the WebDAV ACLs overcomplicated? > >That people want to be able to specify complicated policies, >so once you open the door to ACLs it gets complicated. >And of course the situation here is inherently more >complicated since you're asking people you basically don't >trust to enforce access control for you. > Thanks for explaining. I agree. I guess a shared group key may be a better choice, at least in p2p scenarios, it does not depend on a third party that you don't trust to enforce the access control. > >> >> Req. 12: It SHOULD be possible to limit the impact of badly >> >> behaving P2PSIP nodes on the overall system security. >There SHOULD >> >> be an option to identify malfunctioning or badly behaving nodes, >> >and exclude >> >> or reject them from the P2PSIP system. >> > >> >Hmm... It seems to me that this is already possible at >least in some >> >sense: you use short-lived certificates and then refuse to reissue >> >their certificates. Did you have something else in mind? CRLs? >> > >> I'm not sure about the solution here. I think it may be hard to >> determine the TTL for such kind shor-lived certificates. Misbehaving >> nodes still function in the overlay until its certificate >expires. Too >> short TTL may overload the CA anyway. I don't know how CRLs work in >> the overlay, in a p2p fashion or in a c/s fashion. > >Me neither. And since overlays are resistant to a certain >amount of misbehavior, I don't know if we need to solve this right now. > I prefer to mention the consideration to this problem in the security considerations of the base draft. Haibin >-Ekr > From saumitra@qualcomm.com Thu Jul 2 03:53:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8E23A67A4 for ; Thu, 2 Jul 2009 03:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.159 X-Spam-Level: X-Spam-Status: No, score=-98.159 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FS_REPLICA=0.994, SARE_SPEC_REPLICA_OBFU=1.812, SARE_URI_REPLICA=1.634, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2REYTkaxqAWM for ; Thu, 2 Jul 2009 03:53:27 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E7CF53A6C75 for ; Thu, 2 Jul 2009 03:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1246532029; x=1278068029; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-cr-puzzleid: x-cr-hashedpuzzle:acceptlanguage:content-type: content-transfer-encoding:mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2psip@ietf.org"=20|Date:=20Thu,=202 =20Jul=202009=2003:53:33=20-0700|Subject:=20New=20draft =20on=20enhanced=20replication=20for=20RELOAD |Thread-Topic:=20New=20draft=20on=20enhanced=20replicatio n=20for=20RELOAD|Thread-Index:=20Acn7A1gD/QD2mjveT8mXq3wD GTu8mA=3D=3D|Message-ID:=20<2D06DE445C2ADE44890118C3F449B 96372900CC1@NASANEXMB12.na.qualcomm.com>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-cr-puzzleid:=20{49F159D8-1DCA-4C 30-B65B-7D21123EBC9B}|x-cr-hashedpuzzle:=20AeVl=20Ath3=20 BTaV=20BdFX=20BhXU=20ESLY=20F6Ba=20GU6k=20GpyA=20IBVv=20I 0U9=0D=0A=20Jpyn=20LMrQ=20LbLA=20LgOI=0D=0A=20LpCi=3B1=3B cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA=3BSosha1_v1=3B7 =3B{49F159D8-1DCA-4C30-B65B-7D21123EBC9B}=3BcwBhAHUAbQBpA HQAcgBhAEAAcQB1AGEAbABjAG8AbQBtAC4AYwBvAG0A=3BThu,=0D=0A =2002=20Jul=202009=2010:53:33=0D=0A=20GMT=3BTgBlAHcAIABkA HIAYQBmAHQAIABvAG4AIABlAG4AaABhAG4AYwBlAGQAIAByAGUAcABsAG kAYwBhAHQAaQBvAG4AIABmAG8AcgAgAFIARQBMAE8AQQBEAA=3D=3D |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5663"=3B=20a=3D"20208268"; bh=8+xhf/5QXNFf5/cjlGjuJ8iI8CAQtsiWSk+i3+1w3QQ=; b=d0Rk/xQ9N/Hci5ufoeD8CGtpg0M8eLvX2ju3BM+6DzUOwBbyFZRmziIv N1ua2Pt0HfyGdkof1W/jQFauiEY4gQ63zrbfzvsi7Hb3aeowU6aH6uNSL 2+GNVA9W7GHk4m6Fw7kIe5Eeq4uWauzW9evjCUWkiMj46qMVfZ+Z+KgDq c=; X-IronPort-AV: E=McAfee;i="5300,2777,5663"; a="20208268" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2009 03:53:41 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n62Arfq8021069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 2 Jul 2009 03:53:41 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n62ArZ7A024234 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 2 Jul 2009 03:53:40 -0700 Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Thu, 2 Jul 2009 03:53:39 -0700 From: "Das, Saumitra" To: "p2psip@ietf.org" Date: Thu, 2 Jul 2009 03:53:33 -0700 Thread-Topic: New draft on enhanced replication for RELOAD Thread-Index: Acn7A1gD/QD2mjveT8mXq3wDGTu8mA== Message-ID: <2D06DE445C2ADE44890118C3F449B96372900CC1@NASANEXMB12.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {49F159D8-1DCA-4C30-B65B-7D21123EBC9B} x-cr-hashedpuzzle: AeVl Ath3 BTaV BdFX BhXU ESLY F6Ba GU6k GpyA IBVv I0U9 Jpyn LMrQ LbLA LgOI LpCi; 1; cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {49F159D8-1DCA-4C30-B65B-7D21123EBC9B}; cwBhAHUAbQBpAHQAcgBhAEAAcQB1AGEAbABjAG8AbQBtAC4AYwBvAG0A; Thu, 02 Jul 2009 10:53:33 GMT; TgBlAHcAIABkAHIAYQBmAHQAIABvAG4AIABlAG4AaABhAG4AYwBlAGQAIAByAGUAcABsAGkAYwBhAHQAaQBvAG4AIABmAG8AcgAgAFIARQBMAE8AQQBEAA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] New draft on enhanced replication for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 10:53:27 -0000 Hi all, We have submitted a draft on deterministic replication for data items sto= red on the RELOAD overlay. It supports replication based on the availabilit= y needs of a data item (which may be different based on the type of data) a= nd a method for deterministically choosing replicas which can provide some = load balancing through replica selection. The draft is at: http://www.ietf.org/internet-drafts/draft-vidya-p2psip-rep= lication-00.txt=20 Comments welcome. Best, Saumitra www.saumitra.info=20 From christian.1.schmidt@nsn.com Thu Jul 2 06:32:28 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC9C28C14A for ; Thu, 2 Jul 2009 06:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=1.399, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52GEIBx-4shO for ; Thu, 2 Jul 2009 06:32:27 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 41DE33A6929 for ; Thu, 2 Jul 2009 06:32:27 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n62DWfof017714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Jul 2009 15:32:41 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n62DWcRP016686; Thu, 2 Jul 2009 15:32:40 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 15:32:40 +0200 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: Thu, 2 Jul 2009 15:32:40 +0200 Message-ID: In-Reply-To: <20090702035608.D4CD91C61F6@kilo.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2PSIP Security Requirements Taken Out Fromdraft-matuszewski-p2psip-security-requirements-04 Thread-Index: Acn6yTzwqeV5H2vpSbqF2endSkVJvwATzp3w References: <20090701031556.DDA881C6057@kilo.networkresonance.com><00a001c9fa02$adfae770$0f0ca40a@china.huawei.com> <20090702035608.D4CD91C61F6@kilo.networkresonance.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Eric Rescorla" , "Song Haibin" X-OriginalArrivalTime: 02 Jul 2009 13:32:40.0149 (UTC) FILETIME=[92260850:01C9FB19] Cc: P2PSIP WG Subject: Re: [P2PSIP] P2PSIP Security Requirements Taken Out Fromdraft-matuszewski-p2psip-security-requirements-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 13:32:28 -0000 Hi Eric, Can you please explain your following statement a bit more: =20 "Me neither. And since overlays are resistant to a certain amount=20 of misbehavior, I don't know if we need to solve this right now."Eric Rescorla: What does this mean?=20 Dependent from the percentage of misbehaving peers, a certain percentage of calls will fail? Is this really acceptable? If a call attempt fails, wouldn't this happen to a repeated call attempt as well? Regards Christian Schmidt =20 -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of ext Eric Rescorla Sent: Thursday, July 02, 2009 5:56 AM To: Song Haibin Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] P2PSIP Security Requirements Taken Out Fromdraft-matuszewski-p2psip-security-requirements-04 At Wed, 01 Jul 2009 12:16:12 +0800, Song Haibin wrote: > >I actually think this is a bad idea. Previous experiences with=20 > >trying to design access control systems (see WebDAV ACLs) have=20 > >turned out to be really overcomplicated. As far as I can tell,=20 > >this isn't necessary for the SIP use cases. > > >=20 > As RELOAD is designed to support various usages. Other usages may have this > requirement. For example, we can image group communication scenarios, only > members of a group can retrieve and modify the files belonging to this > group. I think ACL might work. Sure. I'm not saying that one couldn't do an ACL extension to RELOAD at some point in the future to support some future usages. My point is that we don't need it for the current set of applications. > Could you tell me what causes the WebDAV ACLs > overcomplicated? That people want to be able to specify complicated policies, so once you open the door to ACLs it gets complicated. And of course the situation here is inherently more complicated since you're asking people you basically don't trust to enforce access control for you. > >> Req. 12: It SHOULD be possible to limit the impact of badly behaving=20 > >> P2PSIP nodes on the overall system security. There SHOULD be an=20 > >> option to identify malfunctioning or badly behaving nodes,=20 > >and exclude=20 > >> or reject them from the P2PSIP system. > > > >Hmm... It seems to me that this is already possible at least=20 > >in some sense: you use short-lived certificates and then=20 > >refuse to reissue their certificates. Did you have something=20 > >else in mind? CRLs? > > > I'm not sure about the solution here. I think it may be hard to determine > the TTL for such kind shor-lived certificates. Misbehaving nodes still > function in the overlay until its certificate expires. Too short TTL may > overload the CA anyway. I don't know how CRLs work in the overlay, in a p2p > fashion or in a c/s fashion. Me neither. And since overlays are resistant to a certain amount=20 of misbehavior, I don't know if we need to solve this right now. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From ekr@networkresonance.com Thu Jul 2 06:38:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C673D28C234 for ; Thu, 2 Jul 2009 06:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSjWKmSlvcBT for ; Thu, 2 Jul 2009 06:38:31 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 23C9128C232 for ; Thu, 2 Jul 2009 06:38:31 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id DB76A1C62BF; Thu, 2 Jul 2009 06:39:11 -0700 (PDT) Date: Thu, 02 Jul 2009 06:39:11 -0700 From: Eric Rescorla To: "Schmidt, Christian 1. (NSN - DE/Munich)" In-Reply-To: References: <20090701031556.DDA881C6057@kilo.networkresonance.com> <00a001c9fa02$adfae770$0f0ca40a@china.huawei.com> <20090702035608.D4CD91C61F6@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090702133911.DB76A1C62BF@kilo.networkresonance.com> Cc: P2PSIP WG Subject: Re: [P2PSIP] P2PSIP Security Requirements Taken Out Fromdraft-matuszewski-p2psip-security-requirements-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 13:38:31 -0000 At Thu, 2 Jul 2009 15:32:40 +0200, Schmidt, Christian 1. (NSN - DE/Munich) wrote: > "Me neither. And since overlays are resistant to a certain amount > of misbehavior, I don't know if we need to solve this right now."Eric > Rescorla: > > What does this mean? > Dependent from the percentage of misbehaving peers, a certain percentage > of calls will fail? > Is this really acceptable? > If a call attempt fails, wouldn't this happen to a repeated call attempt > as well? Quite possibly, but it's pretty much inherent in the fact that this is operated over a best-effort network and is itself a best-effort network. -Ekr From wang.jun17@zte.com.cn Fri Jul 3 01:56:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0BE43A6BB9; Fri, 3 Jul 2009 01:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.19 X-Spam-Level: X-Spam-Status: No, score=-92.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6lkapsM3oos; Fri, 3 Jul 2009 01:56:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id F22003A67B3; Fri, 3 Jul 2009 01:56:20 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111643559614510; Fri, 3 Jul 2009 16:39:58 +0800 (CST) Received: from [10.30.1.239] by [10.30.17.99] with StormMail ESMTP id 92379.6427399617; Fri, 3 Jul 2009 16:49:30 +0800 (CST) In-Reply-To: <99978d7d0907020154q7518694kd82f54c03ed3615a@mail.gmail.com> To: Tao Ma MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Fri, 3 Jul 2009 16:56:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-03 16:56:29, Serialize complete at 2009-07-03 16:56:29 Content-Type: multipart/alternative; boundary="=_alternative 00311FD8482575E8_=" Cc: standardMINE@googlegroups.com, p2psip@ietf.org, meng.yu@zte.com.cn, p2psip-bounces@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBOZXcgdmVyc2lvbiBmb3IgZHJhZnQg?= =?gb2312?b?IlAyUFNJUCBFdmVudCBOb3RpZmljYXRpb24JRXh0ZW5zaW9uIg==?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:56:22 -0000 This is a multipart message in MIME format. --=_alternative 00311FD8482575E8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIE1hDQogIFRoZSBkYXRhIHN5bmNocm9uaXphdGlvbiBtZXRpb25lZCBpbiB0aGlzIGRyYWZ0 IG1lYW5zIGtlZXBpbmcgdGhlIGRhdGEgDQpjb25zaXN0ZW50IGJldHdlZW4gc3RvcmFnZSBwZWVy IGFuZCBkYXRhIGNhY2hpbmcgY2xpZW50L3BlZXIuDQogIEl0J3MgdmVyeSBzaW1pbGFyIHRvIHRo YXQgeW91IGhhdmUgb3BlbmVkIGEgZHluYW1pYyBjdXJzb3IgYXQgdGhlIA0KY29tcHV0ZXIgQSAs IGFuZCB0aGUgY29ycmVzcG9uZGVudCBkYXRhIHJlc2lkZSBvbiB0aGUgcmVtb3RlIHNlcnZlci4g VGhlbiANCmFub3RoZXIgY29tcHV0ZXIgY2hhbmdlIHRoZSBkYXRhLCB0aGUgZHluYW1pYyBjdXJz b3IgYXQgY29tcHV0ZXIgQSBtdXN0IGJlIA0KcmVmcmVzaGVkIGltbWVkaWF0ZWx5LiBGb3IgdGhl IHAycCBzdG9yYWdlIHN5c3RlbSwgd2UgcHJvcG9zZWQgdGhlIA0KU3Vic3JpYmUvTm90aWZ5IG1l Y2huaXNtIHRvIG1lZXQgdGhpcyByZXF1aXJlbWVudC4NCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIFdhbmcgSnVuKFJ1c3NlbGwgV2Fu ZykNCg0KDQoNCg0KDQpUYW8gTWEgPGFiY2RtYXRhb0BnbWFpbC5jb20+IA0Kt6K8/sjLOiAgcDJw c2lwLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDctMDIgMTY6NTQNCg0KytW8/sjLDQptZW5nLnl1 QHp0ZS5jb20uY24sIHAycHNpcEBpZXRmLm9yZw0Ks63LzQ0Kc3RhbmRhcmRNSU5FQGdvb2dsZWdy b3Vwcy5jb20NCtb3zOINClJlOiBbUDJQU0lQXSBOZXcgdmVyc2lvbiBmb3IgZHJhZnQgIlAyUFNJ UCBFdmVudCBOb3RpZmljYXRpb24gICBFeHRlbnNpb24iDQoNCg0KDQoNCg0KDQpEZWFyIE1lbmcs DQogICAgSSBkb24ndCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgc2NlbmFyaW8gb2YgcmVhbCB0aW1l IGRhdGEgDQpzeW5jaHJvbml6YXRpb24uIENvdWxkIHlvdSBleHBsYWluIGl0IG1vcmUgZGV0YWls ZWQgYnkgc29tZSBleGFtcGxlcz8gDQpCZXNpZGVzLCB0aGUgMy4yLjIgbWVudGlvbmVkIHN1YnNj cmlwdGlvbiBldmVudHMuIFdoYXQgZG9lcyB0aGUgZXZlbnQgDQptZWFuPyBXaGF0IGtpbmQgb2Yg ZXZlbnRzIGRvZXMgYSBzdWJzY3JpYmVyIG5lZWQgdG8ga25vdz8NCiAgQmVzdCBSZWdhcmRzIA0K VGFvIE1hDQoyLEp1bHksMjAwOQ0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxl Y29tbXVuaWNhdGlvbnMsIE1vYmlsZSBsaWZlIGFuZCBuZXcgDQptZWRpYSBsYWINCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQMlBTSVAgbWFpbGluZyBs aXN0DQpQMlBTSVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcDJwc2lwDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRz IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBh cmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHBy ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIu DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00311FD8482575E8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBNYTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFRoZSBkYXRhIHN5bmNocm9uaXph dGlvbiBtZXRpb25lZA0KaW4gdGhpcyBkcmFmdCBtZWFucyBrZWVwaW5nIHRoZSBkYXRhIGNvbnNp c3RlbnQgYmV0d2VlbiBzdG9yYWdlIHBlZXIgYW5kDQpkYXRhIGNhY2hpbmcgY2xpZW50L3BlZXIu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgSXQncyB2 ZXJ5IHNpbWlsYXIgdG8gdGhhdCB5b3UNCmhhdmUgb3BlbmVkIGEgZHluYW1pYyBjdXJzb3IgYXQg dGhlIGNvbXB1dGVyIEEgLCBhbmQgdGhlIGNvcnJlc3BvbmRlbnQNCmRhdGEgcmVzaWRlIG9uIHRo ZSByZW1vdGUgc2VydmVyLiBUaGVuIGFub3RoZXIgY29tcHV0ZXIgY2hhbmdlIHRoZSBkYXRhLA0K dGhlIGR5bmFtaWMgY3Vyc29yIGF0IGNvbXB1dGVyIEEgbXVzdCBiZSByZWZyZXNoZWQgaW1tZWRp YXRlbHkuIEZvciB0aGUNCnAycCBzdG9yYWdlIHN5c3RlbSwgd2UgcHJvcG9zZWQgdGhlIFN1YnNy aWJlL05vdGlmeSBtZWNobmlzbSB0byBtZWV0IHRoaXMNCnJlcXVpcmVtZW50LjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KICZuYnNwOyAmbmJzcDtXYW5nIEp1bihS dXNzZWxsIFdhbmcpPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPlRhbyBNYSAmbHQ7YWJjZG1hdGFvQGdtYWlsLmNvbSZndDs8 L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7Iyzog Jm5ic3A7cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAwOS0wNy0wMiAxNjo1NDwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5tZW5nLnl1QHp0ZS5jb20uY24sIHAycHNp cEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+c3RhbmRhcmRNSU5FQGdvb2dsZWdyb3Vwcy5j b208L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbUDJQU0lQXSBOZXcgdmVyc2lvbiBmb3IgZHJhZnQg JnF1b3Q7UDJQU0lQDQpFdmVudCBOb3RpZmljYXRpb24gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7RXh0ZW5zaW9uJnF1b3Q7PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0zPkRlYXIgTWVuZyw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgSSBkb24n dCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgc2NlbmFyaW8gb2YgcmVhbCB0aW1lDQpkYXRhIHN5bmNo cm9uaXphdGlvbi4gQ291bGQgeW91IGV4cGxhaW4gaXQgbW9yZSBkZXRhaWxlZCBieSBzb21lIGV4 YW1wbGVzPw0KQmVzaWRlcywgdGhlIDMuMi4yIG1lbnRpb25lZCBzdWJzY3JpcHRpb24gZXZlbnRz LiBXaGF0IGRvZXMgdGhlIGV2ZW50IG1lYW4/DQpXaGF0IGtpbmQgb2YgZXZlbnRzIGRvZXMgYSBz dWJzY3JpYmVyIG5lZWQgdG8ga25vdz88YnI+DQombmJzcDsgQmVzdCBSZWdhcmRzIDxicj4NClRh byBNYTxicj4NCjIsSnVseSwyMDA5PGJyPg0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFu ZCBUZWxlY29tbXVuaWNhdGlvbnMsIE1vYmlsZSBsaWZlIGFuZCBuZXcNCm1lZGlhIGxhYjxicj4N CjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KUDJQU0lQIG1haWxpbmcgbGlzdDxicj4NClAyUFNJUEBpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPGJy Pg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZu YnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7 Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5 Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5p emF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5i c3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5i c3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3km bmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rp c2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQm bmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5i c3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xl bHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJz cDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVj ZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNl Jm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5i c3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5i c3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFz Jm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5i c3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9w cmU+ --=_alternative 00311FD8482575E8_=-- From abcdmatao@gmail.com Sun Jul 5 19:00:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8024B3A6AD0; Sun, 5 Jul 2009 19:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.349 X-Spam-Level: * X-Spam-Status: No, score=1.349 tagged_above=-999 required=5 tests=[AWL=-3.947, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRkdC-9L-J-q; Sun, 5 Jul 2009 19:00:48 -0700 (PDT) Received: from mail-vw0-f184.google.com (mail-vw0-f184.google.com [209.85.212.184]) by core3.amsl.com (Postfix) with ESMTP id 0024A3A6876; Sun, 5 Jul 2009 19:00:47 -0700 (PDT) Received: by vwj14 with SMTP id 14so2532089vwj.29 for ; Sun, 05 Jul 2009 19:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yDIGEoVCDmE4W7josEN3zKpKHXkqm0Gbs8EXReIXHgo=; b=gGlTcDCwXNRJkJHocKaLQ0g4RgEWMCIaOh/r3mJOMKpajUJresKb0vpe1sSo2Cl6oV XXMp0/sofE7J41LZcepUca2orhnCSl8V0ZlhcWmWcW6yBW9ye5tczjaS9rYZLmAbXnFN pV0fG5qqyQh31PNSE+NkCG6I7Coeqf6794BSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U9PCmeJuDLCoTEcHrkjwaB5dmGTKtQU8e2RhIqQS5Ay10nzbfXyLAtwYFxnDrGzJwr I0f86/bhuC4hPdfZmRQU8ZLfQiDgyyiUqemCK1u3zDKG18iRFzNBfHu/9DoYhuJEbz1d crKigDpdJRXhgSEU/dMmTvb2QIjP+zM9RM3Xk= MIME-Version: 1.0 Received: by 10.220.74.83 with SMTP id t19mr8295353vcj.98.1246845669509; Sun, 05 Jul 2009 19:01:09 -0700 (PDT) In-Reply-To: References: <99978d7d0907020154q7518694kd82f54c03ed3615a@mail.gmail.com> Date: Mon, 6 Jul 2009 10:01:09 +0800 Message-ID: <99978d7d0907051901i14368329te9efead9523a5853@mail.gmail.com> From: Tao Ma To: wang.jun17@zte.com.cn Content-Type: multipart/alternative; boundary=0016363b870038898c046dffe1c9 Cc: standardMINE@googlegroups.com, p2psip@ietf.org, meng.yu@zte.com.cn, p2psip-bounces@ietf.org Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBOZXcgdmVyc2lvbiBmb3IgZHJhZnQg?= =?gb2312?b?IlAyUFNJUCBFdmVudCBOb3RpZmljYXRpb24gRXh0ZW5zaW9uIg==?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 02:00:49 -0000 --0016363b870038898c046dffe1c9 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, Thanks for reply. I think it's important to keep data consistent in P2P storage system. Maybe the way that this mechanism is integrated into RELOAD needs to be discussed or described further. Tao Ma 6,July,2009 Beijing University of Posts and Telecommunications, Mobile life and new media lab 2009/7/3 > > Hi, Ma > The data synchronization metioned in this draft means keeping the data > consistent between storage peer and data caching client/peer. > It's very similar to that you have opened a dynamic cursor at the > computer A , and the correspondent data reside on the remote server. Then > another computer change the data, the dynamic cursor at computer A must b= e > refreshed immediately. For the p2p storage system, we proposed the > Subsribe/Notify mechnism to meet this requirement. > > --------------------------------------------------- > Wang Jun(Russell Wang) > > > > > *Tao Ma * > =B7=A2=BC=FE=C8=CB: p2psip-bounces@ietf.org > > 2009-07-02 16:54 > =CA=D5=BC=FE=C8=CB > meng.yu@zte.com.cn, p2psip@ietf.org =B3=AD=CB=CD > standardMINE@googlegroups.com =D6=F7=CC=E2 > Re: [P2PSIP] New version for draft "P2PSIP Event Notification > Extension" > > > > > Dear Meng, > I don't really understand the scenario of real time data > synchronization. Could you explain it more detailed by some examples? > Besides, the 3.2.2 mentioned subscription events. What does the event mea= n? > What kind of events does a subscriber need to know? > Best Regards > Tao Ma > 2,July,2009 > Beijing University of Posts and Telecommunications, Mobile life and new > media lab > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > --0016363b870038898c046dffe1c9 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,
   Thanks for reply. I think it's important to keep da= ta consistent in P2P storage system. Maybe the way that this mechanism is i= ntegrated into RELOAD needs to be discussed or described further.
Tao Ma=
6,July,2009
Beijing University of Posts and Telecommunications, Mobile life and new media lab

2009/7/3 <wang.jun17@zte.com.cn>

Hi, Ma
  The data synchronization me= tioned in this draft means keeping the data consistent between storage peer and data caching client/peer.
  It's very similar to th= at you have opened a dynamic cursor at the computer A , and the correspondent data reside on the remote server. Then another computer change the data, the dynamic cursor at computer A must be refreshed immediately. For the p2p storage system, we proposed the Subsribe/Notify mechnism to meet this requirement.
   
----------------------------------= -----------------
   Wang Jun(Russell Wang)


Tao Ma <abcdmatao@gmail.com&= gt;
=B7=A2=BC=FE=C8=CB:  p2psip-bounces@ietf.o= rg

2009-07-02 16:54

=CA=D5=BC=FE=C8= =CB
meng.yu@zte.com.cn, p2psip@ietf.org
=B3=AD=CB=CD
standardMINE@googlegroups.com
=D6=F7=CC=E2
Re: [P2PSIP] New version for = draft "P2PSIP Event Notification        Extension"





Dear Meng,
    I don't really understand the scenario of real time data synchronization. Could you explain it more detailed by some examples? Besides, the 3.2.2 mentioned subscription events. What does the event mean? What kind of events does a subscriber need to know?
  Best Regards
Tao Ma
2,July,2009
Beijing University of Posts and Telecommunications, Mobile life and new media lab
___________________________________= ____________
P2PSIP mailing list
P2PSIP@ietf.org = https://www.ietf.org/mailman/listinfo/p2psip
 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

--0016363b870038898c046dffe1c9-- From jouni.maenpaa@ericsson.com Mon Jul 6 06:30:12 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B0B28C2BF for ; Mon, 6 Jul 2009 06:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6p2Zb8C11-a for ; Mon, 6 Jul 2009 06:30:11 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F04A728C2BC for ; Mon, 6 Jul 2009 06:30:09 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-4e-4a51fc432ed6 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 21.24.13985.34CF15A4; Mon, 6 Jul 2009 15:29:39 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 15:28:28 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 15:28:28 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 87A4823F6 for ; Mon, 6 Jul 2009 16:28:28 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 52C5721A07 for ; Mon, 6 Jul 2009 16:28:28 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 113B021925 for ; Mon, 6 Jul 2009 16:28:28 +0300 (EEST) Message-ID: <4A51FBFC.50801@ericsson.com> Date: Mon, 06 Jul 2009 16:28:28 +0300 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "p2psip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 06 Jul 2009 13:28:28.0306 (UTC) FILETIME=[A5B0D720:01C9FE3D] X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] New draft defining a topology plug-in for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 13:30:12 -0000 Hi folks, We have just submitted a draft that proposes a new topology plug-in for RELOAD. This draft is a merge of two earlier drafts, "A Self-tuning DHT for RELOAD" (draft-maenpaa-p2psip-self-tuning-00) and "A Load Balancing Mechanism for RELOAD" (draft-saumitra-p2psip-loadbalance-00). The draft defines a new topology plug-in for RELOAD that is more appropriate for real world large scale overlays. This topology plug-in implements three important functionalities that allow RELOAD to operate under real world constraints. First, it includes a load balancing algorithm that specifies efficient allocation of load to different nodes in the network. Second, the document describes robust techniques for stabilization of fingers and successors and specifies self tuning mechanisms that allow dynamic and automatic adjustment of parameters needed for these advanced techniques in the topology plug-in. Finally, it specifies a locality aware finger selection algorithm that reduces average lookup latency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-maenpaa-p2psip-topologyplugin-00.txt Comments are welcome! Best regards, Jouni Mäenpää -------8<------- A new version of I-D, draft-maenpaa-p2psip-topologyplugin-00.txt has been successfuly submitted by Jouni Maenpaa and posted to the IETF repository. Filename: draft-maenpaa-p2psip-topologyplugin Revision: 00 Title: A Topology Plug-in for REsource LOcation And Discovery Creation_date: 2009-07-06 WG ID: Independent Submission Number_of_pages: 43 Abstract: REsource LOcation And Discovery (RELOAD) is a peer-to-peer signaling protocol that can be used to maintain an overlay network, and to store data in and retrieve data from the overlay. This document defines a new topology plug-in for RELOAD that is more appropriate for real world large scale overlays. This topology plug-in implements three important functionalities that allow RELOAD to operate under real world constraints. First, it includes a load balancing algorithm that specifies efficient allocation of load to different nodes in the network. Second, the document describes robust techniques for stabilization of fingers and successors and specifies self tuning mechanisms that allow dynamic and automatic adjustment of parameters needed for these advanced techniques in the topology plug-in. Finally, it specifies a locality aware finger selection algorithm that reduces average lookup latency. ------->8------- From brian.rosen@neustar.biz Mon Jul 6 08:32:40 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4774B3A6BAC for ; Mon, 6 Jul 2009 08:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrLuh4Wkx8P0 for ; Mon, 6 Jul 2009 08:32:39 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id B2C693A6D2C for ; Mon, 6 Jul 2009 08:32:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1246894333; x=1246980733; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=fIiwzA8uyvMKCcdAoAVzHLTU/Q7rrfcJgEQ5N4Aumu7zJYjD3lQEqoW48iRkGkEMPLE9xv/9PxUfNJ GmS2RA0g== Received: from ([10.31.13.50]) by chihiron1.nc.neustar.com with ESMTP id 5202942.17506728; Mon, 06 Jul 2009 11:31:52 -0400 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: Mon, 6 Jul 2009 11:31:51 -0400 Message-ID: <580F3FFD9207B545B48957A92BECEE0A31CE41@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Getting a slot at a meeting = list discussion on the draft Thread-Index: Acn+TuI2N8fZH9VoQ9+za63YBC8idQ== From: "Rosen, Brian" To: Subject: [P2PSIP] Getting a slot at a meeting = list discussion on the draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 15:32:40 -0000 Please note that we usually have competition for slots at the meeting. We give priority to drafts that have had discussion on the list. We further reserve the most time for issues that have been aired on the list, but we have not been able to resolve on the list.=20 If you have a draft with no discussion, and no unresolved items, we may not be able to give you time at a meeting to discuss it. =20 Brian From dwcraig@qualcomm.com Mon Jul 6 14:20:14 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F113A6B83 for ; Mon, 6 Jul 2009 14:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt5+N5E4nlXk for ; Mon, 6 Jul 2009 14:20:12 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8FD883A68AC for ; Mon, 6 Jul 2009 14:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=dwcraig@qualcomm.com; q=dns/txt; s=qcdkim; t=1246915195; x=1278451195; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Craig,=20Dave"=20|To:=20" p2psip@ietf.org"=20|Date:=20Mon,=206=20J ul=202009=2014:18:40=20-0700|Subject:=20ICE=20payload=20l ayout=20suggestions=20for=20draft-ietf-p2psip-base |Thread-Topic:=20ICE=20payload=20layout=20suggestions=20f or=20draft-ietf-p2psip-base|Thread-Index:=20Acn+f1V/S6eZl oumR4Ov2L7889dw4g=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_A137D8D774010348AA1D056B52B16053075E7 A8147NASANEXMB03na_"|MIME-Version:=201.0|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5300,2777,5668"=3B=20a=3D"20339791"; bh=nr+jdjShpxsLeca7aIH7i8+mRnto5rGqQ+k5tIvWIlg=; b=azCKZA0+U+YuU7pHJ7oGacx58ANT9qdW/itcos9diYUTGhh0jW3K+Hi5 mOKkI7vhxHr0hLhiwgHR+feLn5DMr/lC0HI+A3RTqIjnboV/C9gRnJyLH YY5ahbyrLh3iUn/RF96741eTiBXfYBSfxRTPwTbjVvxG9ZqqyfVB+M8pY 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5668"; a="20339791" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2009 14:18:43 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n66LIhMd000757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Jul 2009 14:18:43 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n66LIgLr029204 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 6 Jul 2009 14:18:43 -0700 Received: from NASANEXMB03.na.qualcomm.com ([10.45.76.130]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Mon, 6 Jul 2009 14:18:42 -0700 From: "Craig, Dave" To: "p2psip@ietf.org" Date: Mon, 6 Jul 2009 14:18:40 -0700 Thread-Topic: ICE payload layout suggestions for draft-ietf-p2psip-base Thread-Index: Acn+f1V/S6eZloumR4Ov2L7889dw4g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A137D8D774010348AA1D056B52B16053075E7A8147NASANEXMB03na_" MIME-Version: 1.0 Subject: [P2PSIP] ICE payload layout suggestions for draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:20:14 -0000 --_000_A137D8D774010348AA1D056B52B16053075E7A8147NASANEXMB03na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable #1: (5.5.1.3) Binary encoding of IceAttrs for fulfilling IceCandidate mentioned in draft-ietf-p2psip-base-02 The IceAttrs is a customized, binary encoding of the candidate specified for ICE [I-D.draft-ietf-mmusic-ice] and ICE-TCP [I-D.draft-ietf-mmusic-ice-tcp]. This customized version drops the following fields found in ICE: o foundation: There is only one media in use for the RELOAD usage of ICE. All candidates will have either a different type, host candidate, STUN server, or protocol. There will not be any candidates to freeze when ICE starts. o ice-mismatch: RELOAD will prioritize and take TCP transport candidates before UDP transport candidates. o remote-candidate: ICE restart not supported. o component: Same reason as foundation. The candidate attributes TLV structure below is extensible enough to incorporate new formats for candidates as well as extensions that all nodes may not support. struct { uint16 IceAttrType; /* CandidateAttrTypeEnum */ uint16 IceAttrLength; uint8 IceAttrPayload[IceAttrLength]; } IceAttrs; The supported ranges for CandidateAttrType are: o 0 through 127: Comprehension required ICE attributes. A recipient must respond with an error to the ATTACH, if it does not understand these attributes. o 128 through 255: Comprehension optional ICE attributes. A recipient may safely ignore these attributes if it does not understand them. The first three definitions within the comprehension-required range are below. There are no comprehension-optional attributes defined in this document. enum { no_next_attr {0}, ice_base_cand_attr {1}, rel_addr_cand_attr {2} } IceAttrTypeEnum; The definition of the first attribute is the base candidate (ice_base_cand_attr) that denotes the start of a new candidate in the sequence of candidate in the payload. enum { reserved_transport {0}, tcp_simultaneous_open {1}, /* tcp-so */ tcp_active {2}, /* tcp-act */ tcp_passive {3}, /* tcp-pass */ udp {4} } TransportEnum; enum { reserved_candidate {0}, host_candidate {1}, /* host */ srflx_candidate {2}, /* srflx */ prflx_candidate {3}, /* prflx */ relay_candidate {4} /* relay */ } CandidateEnum; struct { TransportEnum Transport; CandidateEnum CandidateType; uint32 Priority; IpAddressPort ConnectionAddressPort; } IceBaseCandAttr; Reflexive and Relayed candidates must have a rel-addr attribute that follows them that is defined below for the rel_addr_cand_attr. struct { IpAddressPort RelAddressPort; } RelAddrCandAttr; Enhancement to AttachReqAns struct { opaque ufrag<0..2^8-1>; opaque password<0..2^8-1>; uint16 application; + uint16 ice_attrs_length; opaque role<0..2^8-1>; - IceCandidate candidates<0..2^16-1>; + IceAttrs ice_attrs[ice_attrs_length]; } AttachReqAns; [Note: Tried to reuse layout schema in draft-ietf-p2psip-base-02] [Problem: Attach-Lite's use of ICE-Lite is not supported in draft-ietf-mmusic-ice-tcp-07. That document requires the Attach-Lite recipient proceed with ICE not ICE Lite if there are TCP candidates. The intended behavior is for Attach-Lite to use RFC4145 instead of ICE-Lite for TCP connections.] #2: (9.5 & 9.9) JoinReq, JoinAns, and Leave layouts for overlay_specific_da= ta struct { AttachReqAns join_ice_attrs; } ChordJoinReq; struct { AttachReqAns join_ice_attrs; } ChordJoinAns; Thanks, Dave --_000_A137D8D774010348AA1D056B52B16053075E7A8147NASANEXMB03na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

#1: (5.5.1.3) Binary encoding of IceAttrs for fulfi= lling IceCandidate

mentioned in draft-ietf-p2psip-base-02

 

 

 

The IceAttrs is a customized, binary encoding of th= e candidate

specified for ICE [I-D.draft-ietf-mmusic-ice] and I= CE-TCP

[I-D.draft-ietf-mmusic-ice-tcp].  This customi= zed version drops

the following fields found in ICE:

 

o foundation: There is only one media in use for th= e RELOAD usage of ICE.

  All candidates will have either a different = type, host candidate, STUN

  server, or protocol.  There will not be= any candidates to freeze when

  ICE starts.

 

o ice-mismatch: RELOAD will prioritize and take TCP transport candidates

  before UDP transport candidates.<= /p>

 

o remote-candidate: ICE restart not supported.=

 

o component: Same reason as foundation.<= /p>

 

 

The candidate attributes TLV structure below is extensible enough to

incorporate new formats for candidates as well as extensions that all

nodes may not support.

 

 

struct {

  uint16      &n= bsp;         IceAttrType; /* CandidateAttrTypeEnum */

  uint16      &n= bsp;         IceAttrLength;

  uint8      &nb= sp;          IceAttrPayload[Ic= eAttrLength];

} IceAttrs;

 

The supported ranges for CandidateAttrType are:

 

o   0 through 127: Comprehension required= ICE attributes.

        &nb= sp;          A recipient must = respond with an error to the

        &nb= sp;          ATTACH, if it doe= s not understand these attributes.

 

o 128 through 255: Comprehension optional ICE attri= butes.

        &nb= sp;          A recipient may s= afely ignore these attributes

        &nb= sp;          if it does not un= derstand them.

 

The first three definitions within the comprehension-required

range are below.  There are no comprehension-o= ptional attributes

defined in this document.

 

enum {

  no_next_attr     &n= bsp;          {0},<= /p>

  ice_base_cand_attr    &n= bsp;     {1},

  rel_addr_cand_attr    &n= bsp;     {2}

} IceAttrTypeEnum;

 

The definition of the first attribute is the base candidate

(ice_base_cand_attr) that denotes the start of a ne= w candidate

in the sequence of candidate in the payload.

 

enum {

  reserved_transport    &n= bsp;     {0},

  tcp_simultaneous_open    = ;   {1}, /* tcp-so */

  tcp_active     &nbs= p;            {2}, /= * tcp-act */

  tcp_passive     &nb= sp;           {3}, /* tcp= -pass */

  udp       = ;             &= nbsp;    {4}

} TransportEnum;

 

 

enum {

  reserved_candidate    &n= bsp;     {0},

  host_candidate     =          {1}, /* host */

  srflx_candidate     = ;        {2}, /* srflx */

  prflx_candidate     = ;        {3}, /* prflx */

  relay_candidate     = ;        {4}  /* relay */

} CandidateEnum;

 

struct {

  TransportEnum     &= nbsp;   Transport;

  CandidateEnum     &= nbsp;   CandidateType;

  uint32      &n= bsp;         Priority;

  IpAddressPort     &= nbsp;   ConnectionAddressPort;

} IceBaseCandAttr;

 

 

Reflexive and Relayed candidates must have a rel-ad= dr attribute

that follows them that is defined below for the rel_addr_cand_attr.

 

struct {

  IpAddressPort     &= nbsp;   RelAddressPort;

} RelAddrCandAttr;

 

Enhancement to AttachReqAns

 

         st= ruct  {

        &nb= sp;  opaque          = ;        ufrag<0..2^8-1>;

        &nb= sp;  opaque          = ;        password<0..2^8-1>;

        &nb= sp;  uint16          = ;        application;

+        &n= bsp; uint16          &nbs= p;       ice_attrs_length;

        &nb= sp;  opaque          = ;        role<0..2^8-1>;

-        &n= bsp; IceCandidate         &nbs= p;  candidates<0..2^16-1>;

+        &n= bsp; IceAttrs           &= nbsp;    ice_attrs[ice_attrs_length];

         } = AttachReqAns;

 

 

 

[Note: Tried to reuse layout schema in draft-ietf-p2psip-base-02]

 

[Problem: Attach-Lite's use of ICE-Lite is not supp= orted in

draft-ietf-mmusic-ice-tcp-07.  That document r= equires the Attach-Lite

recipient proceed with ICE not ICE Lite if there ar= e TCP candidates.

The intended behavior is for Attach-Lite to use RFC= 4145 instead of

ICE-Lite for TCP connections.]

 

#2: (9.5 & 9.9) JoinReq, JoinAns, and Leave lay= outs for overlay_specific_data

 

struct {

 

  AttachReqAns     &n= bsp;    join_ice_attrs;

 

} ChordJoinReq;

 

struct {

 

  AttachReqAns     &n= bsp;    join_ice_attrs;

 

} ChordJoinAns;

 

 

 

Thanks,

Dave

--_000_A137D8D774010348AA1D056B52B16053075E7A8147NASANEXMB03na_-- From sa2086@columbia.edu Mon Jul 6 14:30:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257A43A68A3 for ; Mon, 6 Jul 2009 14:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkzFHMb3QSYV for ; Mon, 6 Jul 2009 14:30:31 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 110893A6BD7 for ; Mon, 6 Jul 2009 14:30:30 -0700 (PDT) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n66LULJT010048; Mon, 6 Jul 2009 17:30:21 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n66LULvx016688; Mon, 6 Jul 2009 17:30:21 -0400 (EDT) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.3/Submit) with ESMTP id n66LULEE016684; Mon, 6 Jul 2009 17:30:21 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Mon, 6 Jul 2009 17:30:21 -0400 (EDT) From: Salman Abdul Baset Sender: sa2086@columbia.edu To: "Craig, Dave" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] ICE payload layout suggestions for draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:30:32 -0000 Hi Dave, Thanks for your suggestion. Indeed, ICE encoding needs an update and we are hoping to update it in the next version of the I-D. Regards, Salman On Mon, 6 Jul 2009, Craig, Dave wrote: > #1: (5.5.1.3) Binary encoding of IceAttrs for fulfilling IceCandidate > > mentioned in draft-ietf-p2psip-base-02 > > > > > > > > The IceAttrs is a customized, binary encoding of the candidate > > specified for ICE [I-D.draft-ietf-mmusic-ice] and ICE-TCP > > [I-D.draft-ietf-mmusic-ice-tcp]. This customized version drops > > the following fields found in ICE: > > > > o foundation: There is only one media in use for the RELOAD usage of ICE. > > All candidates will have either a different type, host candidate, STUN > > server, or protocol. There will not be any candidates to freeze when > > ICE starts. > > > > o ice-mismatch: RELOAD will prioritize and take TCP transport candidates > > before UDP transport candidates. > > > > o remote-candidate: ICE restart not supported. > > > > o component: Same reason as foundation. > > > > > > The candidate attributes TLV structure below is extensible enough to > > incorporate new formats for candidates as well as extensions that all > > nodes may not support. > > > > > > struct { > > uint16 IceAttrType; /* CandidateAttrTypeEnum */ > > uint16 IceAttrLength; > > uint8 IceAttrPayload[IceAttrLength]; > > } IceAttrs; > > > > The supported ranges for CandidateAttrType are: > > > > o 0 through 127: Comprehension required ICE attributes. > > A recipient must respond with an error to the > > ATTACH, if it does not understand these attributes. > > > > o 128 through 255: Comprehension optional ICE attributes. > > A recipient may safely ignore these attributes > > if it does not understand them. > > > > The first three definitions within the comprehension-required > > range are below. There are no comprehension-optional attributes > > defined in this document. > > > > enum { > > no_next_attr {0}, > > ice_base_cand_attr {1}, > > rel_addr_cand_attr {2} > > } IceAttrTypeEnum; > > > > The definition of the first attribute is the base candidate > > (ice_base_cand_attr) that denotes the start of a new candidate > > in the sequence of candidate in the payload. > > > > enum { > > reserved_transport {0}, > > tcp_simultaneous_open {1}, /* tcp-so */ > > tcp_active {2}, /* tcp-act */ > > tcp_passive {3}, /* tcp-pass */ > > udp {4} > > } TransportEnum; > > > > > > enum { > > reserved_candidate {0}, > > host_candidate {1}, /* host */ > > srflx_candidate {2}, /* srflx */ > > prflx_candidate {3}, /* prflx */ > > relay_candidate {4} /* relay */ > > } CandidateEnum; > > > > struct { > > TransportEnum Transport; > > CandidateEnum CandidateType; > > uint32 Priority; > > IpAddressPort ConnectionAddressPort; > > } IceBaseCandAttr; > > > > > > Reflexive and Relayed candidates must have a rel-addr attribute > > that follows them that is defined below for the rel_addr_cand_attr. > > > > struct { > > IpAddressPort RelAddressPort; > > } RelAddrCandAttr; > > > > Enhancement to AttachReqAns > > > > struct { > > opaque ufrag<0..2^8-1>; > > opaque password<0..2^8-1>; > > uint16 application; > > + uint16 ice_attrs_length; > > opaque role<0..2^8-1>; > > - IceCandidate candidates<0..2^16-1>; > > + IceAttrs ice_attrs[ice_attrs_length]; > > } AttachReqAns; > > > > > > > > [Note: Tried to reuse layout schema in draft-ietf-p2psip-base-02] > > > > [Problem: Attach-Lite's use of ICE-Lite is not supported in > > draft-ietf-mmusic-ice-tcp-07. That document requires the Attach-Lite > > recipient proceed with ICE not ICE Lite if there are TCP candidates. > > The intended behavior is for Attach-Lite to use RFC4145 instead of > > ICE-Lite for TCP connections.] > > > > #2: (9.5 & 9.9) JoinReq, JoinAns, and Leave layouts for overlay_specific_data > > > > struct { > > > > AttachReqAns join_ice_attrs; > > > > } ChordJoinReq; > > > > struct { > > > > AttachReqAns join_ice_attrs; > > > > } ChordJoinAns; > > > > Thanks, > Dave > From Even.roni@huawei.com Mon Jul 6 23:10:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504C43A687B for ; Mon, 6 Jul 2009 23:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nb+XQVfOu4jR for ; Mon, 6 Jul 2009 23:10:34 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 315EE3A6847 for ; Mon, 6 Jul 2009 23:10:34 -0700 (PDT) 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 <0KME00I0NEE2TH@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 07 Jul 2009 14:08:26 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KME0023KEE2SD@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 07 Jul 2009 14:08:26 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-30-32.red.bezeqint.net [79.179.30.32]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KME0008MEDX8E@szxml01-in.huawei.com> for p2psip@ietf.org; Tue, 07 Jul 2009 14:08:26 +0800 (CST) Date: Tue, 07 Jul 2009 09:07:47 +0300 From: Roni Even To: p2psip@ietf.org Message-id: <025b01c9fec9$489efb70$d9dcf250$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zmCPzin/2XoEQU6UT3Z2ig)" Content-language: en-us Thread-index: Acn+yP+pxOTCvUp/RfancLbvD4FATw== Subject: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 06:10:35 -0000 This is a multi-part message in MIME format. --Boundary_(ID_zmCPzin/2XoEQU6UT3Z2ig) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, At the previous IETF meeting there was consensus to have direct response as a WG item. The authors of the draft suggested that they will submit a new revision with better text about the relay mode. We did a new revision now in http://www.ietf.org/internet-drafts/draft-jiang-p2psip-relay-02.txt . We feel that we addressed the concerns that were raised during the IETF meeting. We are now looking for input about the draft and more specifically about the relay mode in order to get a final consensus if to add this mode to the work or only have the direct response mode. Please review the draft. Thanks Roni Even --Boundary_(ID_zmCPzin/2XoEQU6UT3Z2ig) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

At the previous IETF meeting there was consensus to = have direct response as a WG item. The authors of the draft suggested that = they will submit a new revision with better text about the relay = mode.

 

We did  a new revision now in http://www.ietf.org/internet-drafts/draft-jiang-p2psip-relay-02.txt .  We feel that we addressed the concerns that were raised during = the IETF meeting.

 

We are now looking for input about the draft and = more specifically about the relay mode in order to get a final consensus if to add this = mode to the work or only have the direct response mode.

 

Please review the draft.

 

Thanks

Roni Even

 

 

--Boundary_(ID_zmCPzin/2XoEQU6UT3Z2ig)-- From melodysong@huawei.com Tue Jul 7 21:04:18 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE8C28C2D7 for ; Tue, 7 Jul 2009 21:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVLj808XFKx5 for ; Tue, 7 Jul 2009 21:04:17 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 0CA8E28C2A0 for ; Tue, 7 Jul 2009 21:04:17 -0700 (PDT) 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 <0KMG001603BJZR@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 08 Jul 2009 12:04:31 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMG004KF3BJM3@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 08 Jul 2009 12:04:31 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMG00D7M3BI2L@szxml06-in.huawei.com> for p2psip@ietf.org; Wed, 08 Jul 2009 12:04:30 +0800 (CST) Date: Wed, 08 Jul 2009 12:04:30 +0800 From: Song Haibin To: 'P2PSIP WG' Message-id: <048201c9ff81$31bace80$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acn/gTF4lqSalaFPTkK+ftlSvo3h5g== Subject: [P2PSIP] changes to the p2psip diagnostics draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 04:04:18 -0000 Hi, We have removed the ECHO method in version 01 due to secruity considerations raised in the mailing list and SF meeting. The diagnostics information in the base draft has been merged into the document. We also changed the table of contents and define extensible diagnostic flags. Please read the document and we will be glad to receive more comments as input. http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-01 Best Regards, Haibin Skype: alexsonghw From ekr@networkresonance.com Wed Jul 8 09:41:13 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427AE3A6ADF for ; Wed, 8 Jul 2009 09:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf9Mmi1+IsCb for ; Wed, 8 Jul 2009 09:41:12 -0700 (PDT) Received: from kilo.networkresonance.com (dhcp-128-107-46-218.cisco.com [128.107.46.218]) by core3.amsl.com (Postfix) with ESMTP id 8F4713A6812 for ; Wed, 8 Jul 2009 09:41:12 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 1DAC91C7B43; Wed, 8 Jul 2009 09:42:35 -0700 (PDT) Date: Wed, 08 Jul 2009 09:42:34 -0700 From: Eric Rescorla To: Song Haibin In-Reply-To: <003701c9faf6$ccb829d0$0f0ca40a@china.huawei.com> References: <20090702035608.D4CD91C61F6@kilo.networkresonance.com> <003701c9faf6$ccb829d0$0f0ca40a@china.huawei.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090708164235.1DAC91C7B43@kilo.networkresonance.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] P2PSIP Security Requirements Taken Out From draft-matuszewski-p2psip-security-requirements-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 16:41:13 -0000 At Thu, 02 Jul 2009 17:23:45 +0800, Song Haibin wrote: > >> >> Req. 12: It SHOULD be possible to limit the impact of badly > >> >> behaving P2PSIP nodes on the overall system security. > >There SHOULD > >> >> be an option to identify malfunctioning or badly behaving nodes, > >> >and exclude > >> >> or reject them from the P2PSIP system. > >> > > >> >Hmm... It seems to me that this is already possible at > >least in some > >> >sense: you use short-lived certificates and then refuse to reissue > >> >their certificates. Did you have something else in mind? CRLs? > >> > > >> I'm not sure about the solution here. I think it may be hard to > >> determine the TTL for such kind shor-lived certificates. Misbehaving > >> nodes still function in the overlay until its certificate > >expires. Too > >> short TTL may overload the CA anyway. I don't know how CRLs work in > >> the overlay, in a p2p fashion or in a c/s fashion. > > > >Me neither. And since overlays are resistant to a certain > >amount of misbehavior, I don't know if we need to solve this right now. > > > > I prefer to mention the consideration to this problem in the security > considerations of the base draft. I don't have a problem with mentioning this issue. -Ekr From ekr@networkresonance.com Wed Jul 8 10:02:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C543A67A5 for ; Wed, 8 Jul 2009 10:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiS3oj14HoQE for ; Wed, 8 Jul 2009 10:02:08 -0700 (PDT) Received: from kilo.networkresonance.com (dhcp-128-107-46-218.cisco.com [128.107.46.218]) by core3.amsl.com (Postfix) with ESMTP id 1E39F3A67A1 for ; Wed, 8 Jul 2009 10:02:08 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D04521C7B4D; Wed, 8 Jul 2009 10:03:25 -0700 (PDT) Date: Wed, 08 Jul 2009 10:03:25 -0700 From: Eric Rescorla To: "Narayanan, Vidya" In-Reply-To: References: <2D06DE445C2ADE44890118C3F449B9636D582DD6@NASANEXMB12.na.qualcomm.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090708170325.D04521C7B4D@kilo.networkresonance.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] targeted requests X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 17:02:08 -0000 At Tue, 24 Mar 2009 18:21:09 -0700, Narayanan, Vidya wrote: > > Based on section 9.4, successor replication is already supported in RELOAD. However, the following sentence makes it unsuitable for a generic targeted STORE request, such as would be needed for caching: > > "The peers receiving these check they came from an > appropriate predecessor in their neighbor table and that they are in > a range that this predecessor is responsible for, and then they store > the data." > > I am not sure that the above check really buys much anyway. So, perhaps we can do without it. Any node may reject a STORE request that it is unable to honor anyway. Hmm... I don't think this is true. If a node receives a STORE request which it is supposed to honor (i.e., it's responsible for the resource-id) and the request is otherwise valid, it must process it and store the data. If it is unable to do so for some reason (e.g., it's out of disk space), then it needs to exit the overlay. Otherwise, we've created a condition where the overlay can be permanently unreliable. The converse of this is that nodes need to know which requests they are required to honor. > Also, I notice that section 9 is a little light on normative text. It probably needs a further scrub to ensure it is implementable in an interoperable fashion. Specific comments are welcome here. -Ekr From ekr@networkresonance.com Wed Jul 8 10:42:42 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253FF3A6F70 for ; Wed, 8 Jul 2009 10:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrrVzbjesv6n for ; Wed, 8 Jul 2009 10:42:40 -0700 (PDT) Received: from kilo.networkresonance.com (dhcp-128-107-46-218.cisco.com [128.107.46.218]) by core3.amsl.com (Postfix) with ESMTP id 668EB3A6C11 for ; Wed, 8 Jul 2009 10:42:39 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E696A1C7B5B; Wed, 8 Jul 2009 10:43:19 -0700 (PDT) Date: Wed, 08 Jul 2009 10:43:19 -0700 From: Eric Rescorla To: "Narayanan, Vidya" In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 17:42:42 -0000 At Wed, 1 Jul 2009 12:18:13 -0700, Narayanan, Vidya wrote: > The client operation in RELOAD is currently underspecified and > cannot be implemented based on the spec. I'm certainly prepared to believe that's correct, but I'm not really getting that from your message. From my perspective, the major feature of the RELOAD client design is that there *isn't* any special support for clients, but that it just drops out of the rest of the specified protocol. > Message changes necessary to support clients: > --------------------------------------------- > We need to introduce a "Node Type" in the JOIN Request message that > indicates that the joining node wishes to do so as a client. Also, > Update messages need to have a "case clients" and the "case full" > needs to include client information. In the current design, clients simply don't send Join or Update, so this isn't an issue. Because they don't really participate in either the storage or routing fabric, as far as I can tell they don't need to do either. > I suggest adding a section on clients - suggested text below: > > Clients: > -------- > Clients are nodes that may provide and receive services in an > overlay without participating in overlay routing or incurring the > same amount of maintenance overhead as the overlay peers. Clients > are modeled as close to peers as possible in terms of overlay > functionality. In order to allow these nodes to participate in the > overlay without inherently being a routing member of the overlay, > some changes are required to the join process and the manner in > which neighbor relationships are handled for such nodes. However, > all other procedures (e.g., data management using STORE, FETCH, > etc.) are handled in exactly the same way as for any other peer in > the overlay. > > We denote the point of attachment of the Non-Routing Peer on to the > overlay as Overlay Attachment Point (OAP). The peer responsible for > the node ID of the client provides the OAP functionality. This > allows the integration of clients into the architecture with the > least deviation from the peer. Hence, any node that wishes to be a > client finds the node that owns its identity space and attaches to > it. By definition, any node serving as a peer in the overlay MUST > provide the OAP functionality as well. The mode of using a > different node as the OAP may be allowed as an extension to this > protocol - this can be done for availability or load balancing > reasons, for instance. > > Clients obtain overlay node identities just like peers do. Hence, > the enrollment server may be completely unaware of the distinction > between a peer and a client. By virtue of this, the enrollment > procedure is identical for peers and clients. The join procedure is > somewhat simplified for a client and the section below describes > that process. All data management operations to/from a client are > indistinguishable from those of a peer. > > The main difference between a client and a peer is that a client > only has a single neighbor in the overlay, i.e., the OAP. The > client routes all messages through the OAP - i.e., it has a default > route with the OAP as next hop that is used for all messages. The > OAP has the client as a neighbor and has it in its routing table. > None of the nodes in the overlay except the OAP are aware of the > presence of the client. The messages to/from a client are natively > routed on the overlay. All messages that are sent to the client > arrive at the OAP by regular overlay routing (since it owns the > identity space that includes that of the client). The OAP then > looks up its routing table to route the message to the client. > > The OAP may make use of the presence of a client to offload some of > its storage responsibilities or to replicate data stored at it. > This may be mutually beneficial in some cases - e.g., the client may > be limited in terms of bandwidth and battery, while the OAP may be > limited in memory. However, this is out of scope for this document > itself and any such storage sharing that occurs between a client and > OAP is not visible to the rest of the overlay. Hence, any such > thing must be managed out of band between the OAP and the client. I agree with almost all of this text, but it's not normative and I'm not sure really clarifies things that much. As far as clients storing data for OAPs goes, IMO that should be out of scope of the protocol. If clients and OAPs want to design some new protocol that handles that great, but it's not RELOADs business. > Client Bootstrap Process: > ------------------------- > A client obtains a list of bootstrap peers from the enrollment > server as any other node in the overlay. The client triggers the > join process the same way as a peer does. But, the process is a bit > more abridged than for a normal peer. It is described below: > > 1. Client connects to its chosen bootstrap node. The client MUST > form a TLS session with the bootstrap node, using the certificate or > PSK required for overlay membership. 2. The client sends a Join > request message to its own Node-ID c, through the BP. The Join > Request message indicates that the joining entity is a client (with > Node Type being set to Client). This is routed to the admitting > peer (AP). The AP sends a response to the Join, after noting that > it must serve as the OAP. 3. The client also sends an Attach > request message to c through the BP. This may be sent in parallel > with the Join message. The AP sends an Attach response, resulting > in connection establishment between the client and AP. At this > point, the AP has the client included in its routing and connection > tables and the client has established a default route through the > AP. The join process is now complete. > > The OAP MUST NOT send any Update messages to other peers in the > overlay as a result of a client joining the overlay. The OAP simply > updates its routing and connection tables with the client > information. The client does the same. The OAP may, however, > follow up the join process with a series of STORE request messages > to transfer some data it stores to the client. I disaree with this: the client should not be sending a Join because that indicates the desire to be a peer. There is no need for the join as mere attachment enables direct routing to the client from the OAP. > Impact of Churn on Clients: > ---------------------------- > As the ownership of the overlay identity space changes, the clients > may be affected. For instance, if the OAP to which a client is > attached leaves the overlay or fails, the client needs to find the > appropriate OAP to attach to. Also, when the identity ownership > changes due to a new peer attaching between the OAP and the client > in the identity space, the client needs to use the new peer as its > OAP. Essentially, the need to change OAP may arise from one of the > following three conditions: > > * A new peer joined the overlay with an identity that lies between > * the identities of a client and its OAP > > * The OAP of a client performs a graceful leave from the overlay > > * The OAP of a client abruptly leaves the overlay or fails > > These three cases are explained below. > > Handling New Peers: > ------------------- > > Consider the case where a client (C1) is attached to an OAP (OAP1). > A new peer, P, attaches to the overlay, with an identity that falls > between C1's and OAP1's identity. P is now responsible for the > identity that belongs to C1 and hence needs to serve as the OAP to > C1 (say, OAP2). When P completes its Join process, OAP1 detects > that it no longer owns the identity corresponding to C1. OAP1 now > sends an Update message to C1, indicating that it has a new > neighbor. The Update message provides information about P to C1. > Upon receiving the Update message, C1 sends a Join Request via OAP1 > to P. The difference between this JOIN process and the regular one > is that C1 can perform this Join via OAP1 instead of finding a > bootstrap peer to perform the join through. Since P is part of the > overlay and is OAP1's neighbor, OAP1 can reach P directly, thereby > greatly reducing the number of hops the Join messages need to > traverse. Once the new Join process completes, P takes over as C1' > s OAP (OAP2). C1 may send a Leave Request to OAP1 subsequent to > its attachment to OAP2 - this will trigger cleaning up of state > corresponding to C1 at OAP1. > > If OAP1 stored any of its data at C1, C1 must transfer that back to > OAP1 before joining again with OAP2. The mechanism to handle this > is out of scope of this specification. > > When a change in the identity space ownership causes the OAP of a > particular node to change, the present OAP MUST send an Update > message to the client, indicating that it has a new neighbor. Upon > receiving the update message, the client MUST send a Join message to > the new OAP - this JOIN message can be routed through its current > OAP. The client SHOULD send a Leave request to its old OAP, once it > has successfully attached to the new OAP. In general, whenever a peer's view of its neighbor changes it should Update all its neighbors. As "client" isn't a first-class term in RELOAD, this implies clients as well. I agree we should explicitly state that clients need to disconnect and reconnect to the new responsible peer. As indicated above, I believe the discussion of Join is incorrect. > There is an issue that nodes may send attach messages to the > client's node id when looking for a finger. The client needs to > reject such Attach requests coming to it. However, the client will > be unable to distinguish Attach messages that are being sent to it > to really set up an end-to-end connection for other purposes. We > may want to consider introducing a "purpose" in the Attach request > messages that indicate the reason for the Attach. This will make it > possible for the client to reject a request that is sent to > establish a finger. The node sending the Attach request can then > slightly alter the resource id to issue another request. There is supposed to be an AppAttach message that makes this clear. It just somehow didn't make it into the draft. It will be in the next revision. -Ekr From peter.slow@gmail.com Thu Jul 9 07:09:48 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B5728C1F4 for ; Thu, 9 Jul 2009 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hndNbzh61AOZ for ; Thu, 9 Jul 2009 07:09:47 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id A686228C21F for ; Thu, 9 Jul 2009 07:09:37 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so57736qwd.31 for ; Thu, 09 Jul 2009 07:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=uuqo3+2xLDfkdcScgoFUMl8zI9edzWFco0jX1jyPzpI=; b=Zha6URDRZpyEY+f+sXzNrJqpHv6jfnz/d8zhwOzwFrIq5Pvz6dOd/WDaq/MMXtm7K5 mEq1ko4STL/FtXQwPtvwJRLeH34Z6bwfJKwd8Bm6fJOBLaLbzvQx6blqFBI+iLrFs33v OooctW5/iMZF+h3Fw9pQS0Aec/b5nm13YnihU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=M3uAzqIuVJo9oRtfatTSYQCyuL6Il9AvzG9fOi2gGOQI0Z4bEflatai6/hDD/O+4hk 3NGW10uBqp9za1p5goFgTXpm8DPuV4h1FjC3MjhQvDKBQNYPZd7/0T4uY0FH3MKadDka QoWrJCo6mDLk7wM5L7GKpA8Riy92nO2rf50HY= MIME-Version: 1.0 Received: by 10.231.16.138 with SMTP id o10mr248504iba.13.1247148603098; Thu, 09 Jul 2009 07:10:03 -0700 (PDT) Date: Thu, 9 Jul 2009 10:10:03 -0400 Message-ID: <53fc16d40907090710n5e67dfd3j2191a15c0a5e72b0@mail.gmail.com> From: Peter Slow To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Hello Everyone X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:24:17 -0000 Hi there, My name is Pete and I heard about P2P SIP at a (SIP Specific, not vendor-specific) "Advancements in SIP" session at Cisco live this past week. As someone who has done ridiculous amounts of CallManager configuration and troubleshooting, coming from a routing and switching background, the fact that I have to deal with troubleshooting call routing loops has always bothered me. Why should I have to go to clusters of callmanagers or other h.323 or SIP entities, all integrated with each other, and configure what are essentially static routes on them, pointing number patterns at the appropriate entities? I asked this question of some people while I was at TAC and they looked at me like I'd had too much NyQuil. Devices know what DNs are on them, and call processing entities know what patterns are configured for access to local gateways... Why do I need to go to other entities and configure these patterns etc repeatedly? Why can't they just tell each other? This has always seemed sub-optimal and inefficient to me. This is my understanding of what P2P SIP is meant to help with or do, and I would like to contribute thoughts and ideas from the perspective of someone whose done lots of both voice and routing and switching design and integration =) ...I'd like to not have to configure route patterns more than once. In my humble opinion, afterwards, some sort of routing protocol should take care of telling other clusters and entities about patterns and devices and RP-ish things like split-horizon should be used to make sure that we don't create call routing loops by sending calls back to where they originated from. (with minor exceptions for certain callflows.) Nice to meet you all, Peter From vidyan@qualcomm.com Thu Jul 9 14:02:48 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386F628C158 for ; Thu, 9 Jul 2009 14:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjqCqq7qc+dT for ; Thu, 9 Jul 2009 14:02:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CCB643A6A5A for ; Thu, 9 Jul 2009 14:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1247173388; x=1278709388; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Xiao,=20Lin=20(NSN=20-=20CN/Beijing)"=20,=0D=0A=20=20=20=20=20=20=20=20"p2psip@ietf.org"=0D =0A=09|Date:=20Thu,=209=20Jul=202009=201 4:03:02=20-0700|Subject:=20RE:=20[P2PSIP]=20Client=20oper ation=20in=20RELOAD|Thread-Topic:=20[P2PSIP]=20Client=20o peration=20in=20RELOAD|Thread-Index:=20Acn6gK3A2+lg4CfyRs eVJJ+XHcOuPwAPYOawARxF3PA=3D|Message-ID:=20|References:=20=0D=0A=20<5D84FDD8D5DC8646 B9F73CF1EFD1BFA4822337@CNBEEXC007.nsn-intra.net> |In-Reply-To:=20<5D84FDD8D5DC8646B9F73CF1EFD1BFA4822337@C NBEEXC007.nsn-intra.net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5671"=3B=20a=3D"20517342"; bh=oJWEgrEXEq4o/w3nYp2ylvimXGZYmTxP84eE/L4fZ50=; b=soFcTMAiq3+dqLl1nWU2bx6r1k/fKS12Pq8bSJRGqisU87GwXYn0v1MG D6A4wh8hWqWrFAUYIiMMgxqm8CwjxzF2lZjR3ILbJCW9M9berqGV+vKop ugrRriixBheqdo9Wn+kIp2M1DqOKOgTxeoAu95X16TyeIxp0KjTH2B2Mv Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5671"; a="20517342" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2009 14:03:07 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n69L37xu013817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Jul 2009 14:03:07 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n69L34sF026954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Jul 2009 14:03:04 -0700 (PDT) Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 9 Jul 2009 14:03:03 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Thu, 9 Jul 2009 14:03:04 -0700 From: "Narayanan, Vidya" To: "Xiao, Lin (NSN - CN/Beijing)" , "p2psip@ietf.org" Date: Thu, 9 Jul 2009 14:03:02 -0700 Thread-Topic: [P2PSIP] Client operation in RELOAD Thread-Index: Acn6gK3A2+lg4CfyRseVJJ+XHcOuPwAPYOawARxF3PA= Message-ID: References: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4822337@CNBEEXC007.nsn-intra.net> In-Reply-To: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4822337@CNBEEXC007.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 21:02:48 -0000 Hi Lin, > -----Original Message----- > From: Xiao, Lin (NSN - CN/Beijing) [mailto:lin.xiao@nsn.com] > Sent: Wednesday, July 01, 2009 8:43 PM > To: Narayanan, Vidya; p2psip@ietf.org > Subject: RE: [P2PSIP] Client operation in RELOAD >=20 > Hi vidyan, >=20 > I also agree with you to give a deeper discussion and specification on > RELOAD clients. IMO, all client related specification could be taken > out > side of BASE draft. RELOAD BASE just need give a general rule for > overlay construction and common behavior of both peers and clients. >=20 This may be okay, although supporting client attachment at the identity own= er seems fundamental and hence, I suggested that be part of the base draft.= =20 > In your email below, you defined clients as nodes without routing > responsibility.=20 It should also say no storage responsibility. Any storage that a client ma= y offer is outside the scope of RELOAD itself and should be managed out of = band. So, from the overlay's perspective, the client has no storage respon= sibility.=20 > However, in RELOAD Base, clients was defined as nodes > which have Node-ID but do not participate in routing or storage. That > means, They could be nodes with routing but without storage. Three > kinds > of clients has been analysed in draft > [draft-xiao-p2psip-client-routing-00.txt], > http://www.ietf.org/internet-drafts/draft-xiao-p2psip-client-routing- > 00. > txt. This small difference may need to be negotiate with RELOAD Base. > No > matter what the result will be, at least, we should discuss something > basing on a same terminology, right? >=20 Using the same terminology would be good. I do, however, think that we sho= uld not get into storage on clients or routing without storage, etc. It wi= ll fundamentally complicate the DHT and is best kept simple with clients ha= ving no routing or storage from the overlay's perspective. =20 > You recommend only a single neighbour for each client. IMO, a client > can > maintain more than one neighbours, but only keeps one entry in its > Routing Table at a time. It not only ensures all messages from/to the > client are through the OAP, but also make sure the client could be > quickly hand over to a Direct Attachment Point (DAP), which can be > selected directly from the neighbours, when necessary. It offers a > seamless transfer from client to eclient. >=20 Sure, I didn't mean to exclude this - more often than not, however, having = more connections may not be a necessary burden on the client. But, a clien= t may optionally choose to do this as you say. =20 > By the way. in my draft [draft-xiao-p2psip-client-routing-00.txt], the > Routing Client and Pure Client defined there are in the scope of your > client discussion with similar concern. We do need a unified protocol > for Reload clients. >=20 We do need to define how clients work in detail. Especially for attachment= at arbitrary points, I think it is best if mobility is handled natively wi= thout needing the client to re-store all data with a new destination list u= pon movement. This will be similar to the annoyance of embedding IP addres= ses in applications and all the issues that has caused over the years and I= 'd really like to avoid that here.=20 Regards, Vidya >=20 > Best Regards > Lin >=20 >=20 >=20 > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf > Of ext Narayanan, Vidya > Sent: Thursday, July 02, 2009 3:18 AM > To: p2psip@ietf.org > Subject: [P2PSIP] Client operation in RELOAD >=20 > The client operation in RELOAD is currently underspecified and cannot > be > implemented based on the spec. Here are the procedures that need to be > specified to support client behavior with attachment at the identity > owner. For attachment at any other arbitrary point, a lot more thought > needs to be put in to ensure support for mobility and stability of > operation. My suggestion is that it is better left outside the scope > of > this draft and defined separately. In this case, RELOAD will only > support attachment at the identity owner, which seems very reasonable. >=20 > Message changes necessary to support clients: > --------------------------------------------- > We need to introduce a "Node Type" in the JOIN Request message that > indicates that the joining node wishes to do so as a client. Also, > Update messages need to have a "case clients" and the "case full" needs > to include client information. >=20 > I suggest adding a section on clients - suggested text below: >=20 > Clients: > -------- > Clients are nodes that may provide and receive services in an overlay > without participating in overlay routing or incurring the same amount > of > maintenance overhead as the overlay peers. Clients are modeled as > close > to peers as possible in terms of overlay functionality. In order to > allow these nodes to participate in the overlay without inherently > being > a routing member of the overlay, some changes are required to the join > process and the manner in which neighbor relationships are handled for > such nodes. However, all other procedures (e.g., data management using > STORE, FETCH, etc.) are handled in exactly the same way as for any > other > peer in the overlay. >=20 > We denote the point of attachment of the Non-Routing Peer on to the > overlay as Overlay Attachment Point (OAP). The peer responsible for > the > node ID of the client provides the OAP functionality. This allows the > integration of clients into the architecture with the least deviation > from the peer. Hence, any node that wishes to be a client finds the > node that owns its identity space and attaches to it. By definition, > any node serving as a peer in the overlay MUST provide the OAP > functionality as well. The mode of using a different node as the OAP > may be allowed as an extension to this protocol - this can be done for > availability or load balancing reasons, for instance. >=20 > Clients obtain overlay node identities just like peers do. Hence, the > enrollment server may be completely unaware of the distinction between > a > peer and a client. By virtue of this, the enrollment procedure is > identical for peers and clients. The join procedure is somewhat > simplified for a client and the section below describes that process. > All data management operations to/from a client are indistinguishable > from those of a peer. >=20 > The main difference between a client and a peer is that a client only > has a single neighbor in the overlay, i.e., the OAP. The client routes > all messages through the OAP - i.e., it has a default route with the > OAP > as next hop that is used for all messages. The OAP has the client as a > neighbor and has it in its routing table. None of the nodes in the > overlay except the OAP are aware of the presence of the client. The > messages to/from a client are natively routed on the overlay. All > messages that are sent to the client arrive at the OAP by regular > overlay routing (since it owns the identity space that includes that of > the client). The OAP then looks up its routing table to route the > message to the client. >=20 > The OAP may make use of the presence of a client to offload some of its > storage responsibilities or to replicate data stored at it. This may > be > mutually beneficial in some cases - e.g., the client may be limited in > terms of bandwidth and battery, while the OAP may be limited in memory. > However, this is out of scope for this document itself and any such > storage sharing that occurs between a client and OAP is not visible to > the rest of the overlay. Hence, any such thing must be managed out of > band between the OAP and the client. >=20 > Client Bootstrap Process: > ------------------------- > A client obtains a list of bootstrap peers from the enrollment server > as > any other node in the overlay. The client triggers the join process > the > same way as a peer does. But, the process is a bit more abridged than > for a normal peer. It is described below: >=20 > 1. Client connects to its chosen bootstrap node. The client MUST form > a > TLS session with the bootstrap node, using the certificate or PSK > required for overlay membership. > 2. The client sends a Join request message to its own Node-ID c, > through the BP. The Join Request message indicates that the joining > entity is a client (with Node Type being set to Client). This is > routed > to the admitting peer (AP). The AP sends a response to the Join, after > noting that it must serve as the OAP. > 3. The client also sends an Attach request message to c through the > BP. > This may be sent in parallel with the Join message. The AP sends an > Attach response, resulting in connection establishment between the > client and AP. At this point, the AP has the client included in its > routing and connection tables and the client has established a default > route through the AP. The join process is now complete. >=20 > The OAP MUST NOT send any Update messages to other peers in the overlay > as a result of a client joining the overlay. The OAP simply updates > its > routing and connection tables with the client information. The client > does the same. The OAP may, however, follow up the join process with a > series of STORE request messages to transfer some data it stores to the > client. >=20 > Impact of Churn on Clients: > ---------------------------- > As the ownership of the overlay identity space changes, the clients may > be affected. For instance, if the OAP to which a client is attached > leaves the overlay or fails, the client needs to find the appropriate > OAP to attach to. Also, when the identity ownership changes due to a > new peer attaching between the OAP and the client in the identity > space, > the client needs to use the new peer as its OAP. Essentially, the > need > to change OAP may arise from one of the following three conditions: >=20 > * A new peer joined the overlay with an identity that lies between the > identities of a client and its OAP >=20 > * The OAP of a client performs a graceful leave from the overlay >=20 > * The OAP of a client abruptly leaves the overlay or fails >=20 > These three cases are explained below. >=20 > Handling New Peers: > ------------------- >=20 > Consider the case where a client (C1) is attached to an OAP (OAP1). A > new peer, P, attaches to the overlay, with an identity that falls > between C1's and OAP1's identity. P is now responsible for the > identity > that belongs to C1 and hence needs to serve as the OAP to C1 (say, > OAP2). When P completes its Join process, OAP1 detects that it no > longer owns the identity corresponding to C1. OAP1 now sends an Update > message to C1, indicating that it has a new neighbor. The Update > message provides information about P to C1. Upon receiving the Update > message, C1 sends a Join Request via OAP1 to P. The difference between > this JOIN process and the regular one is that C1 can perform this Join > via OAP1 instead of finding a bootstrap peer to perform the join > through. Since P is part of the overlay and is OAP1's neighbor, OAP1 > can reach P directly, thereby greatly reducing the number of hops the > Join messages need to traverse. Once the new Join process completes, P > takes over as C1' > s OAP (OAP2). C1 may send a Leave Request to OAP1 subsequent to its > attachment to OAP2 - this will trigger cleaning up of state > corresponding to C1 at OAP1. >=20 > If OAP1 stored any of its data at C1, C1 must transfer that back to > OAP1 > before joining again with OAP2. The mechanism to handle this is out of > scope of this specification. >=20 > When a change in the identity space ownership causes the OAP of a > particular node to change, the present OAP MUST send an Update message > to the client, indicating that it has a new neighbor. Upon receiving > the update message, the client MUST send a Join message to the new OAP > - > this JOIN message can be routed through its current OAP. The client > SHOULD send a Leave request to its old OAP, once it has successfully > attached to the new OAP. >=20 > Graceful Leave of an OAP: > ------------------------- > When an OAP gracefully leaves an overlay, it typically sends a LEAVE > request message to all its neighbors. In addition, the OAP SHOULD send > a Leave Request message to the client. Further, the OAP SHOULD also > send an Update message to the client, containing information about its > successor, which will be the new OAP for the client. When the client > receives such an Update Request, it MUST send a Join Request message to > its new OAP. If the old OAP is able to assist in the Join process, the > Join messages can traverse through it to set up the connection between > the client and its new OAP. However, if the old OAP leaves the overlay > prior to that process, the client needs to find a bootstrap peer and > route its Join Request message through that peer to its new OAP, in > which case, the procedure becomes similar to the failure of an OAP case > described below. >=20 > Failure of an OAP: > ------------------ > An abrupt leave or a failure of an OAP implies that there is no active > messaging from the OAP to its clients indicating that an OAP change is > required. In this case, the client will detect the absence of its OAP > due to a timeout indicating that the OAP is unreachable. The client > then needs to perform the Join process via a bootstrap peer in the > overlay to find its new OAP. >=20 > Impact on attach messages: > --------------------------- > There is an issue that nodes may send attach messages to the client's > node id when looking for a finger. The client needs to reject such > Attach requests coming to it. However, the client will be unable to > distinguish Attach messages that are being sent to it to really set up > an end-to-end connection for other purposes. We may want to consider > introducing a "purpose" in the Attach request messages that indicate > the > reason for the Attach. This will make it possible for the client to > reject a request that is sent to establish a finger. The node sending > the Attach request can then slightly alter the resource id to issue > another request. >=20 > Thanks, > Vidya > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From vidyan@qualcomm.com Thu Jul 9 14:02:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3043A3A6A5A for ; Thu, 9 Jul 2009 14:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Czy8s94F2eva for ; Thu, 9 Jul 2009 14:02:42 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5652328C14F for ; Thu, 9 Jul 2009 14:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1247173390; x=1278709390; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Eric=20Rescorla=20|CC:=20"p2 psip@ietf.org"=20|Date:=20Thu,=209=20Jul =202009=2014:03:08=20-0700|Subject:=20RE:=20[P2PSIP]=20Cl ient=20operation=20in=20RELOAD|Thread-Topic:=20[P2PSIP] =20Client=20operation=20in=20RELOAD|Thread-Index:=20Acn/8 3bKsY5CD/owRDShSCfqkHqXIQA5KjSw|Message-ID:=20|References:=20=0D=0A=20<2009070817431 9.E696A1C7B5B@kilo.networkresonance.com>|In-Reply-To:=20< 20090708174319.E696A1C7B5B@kilo.networkresonance.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5671"=3B=20a=3D"20517345"; bh=h9Z8T9CGLjMSb+wvYLYkX/XPgZxyL2zZSZlqA6WHvVw=; b=R11wpbgsevyucuCM0TrFguIc+zdPByrYgLbnE6pG5UXh8sX6CMLqWWzq etAAsu5gXxLw0EgUbnDj5GwXPifHkIUj8CuobXBK84YdBkX3ruYZzyVRx WE1oJbrh+qpTM/QVtfU7UaABmu1fWKmBoiRpnoY7xnklV5jAhVRh3XWvz Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5671"; a="20517345" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2009 14:03:10 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n69L3Ata013830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Jul 2009 14:03:10 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n69L39jE019029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Jul 2009 14:03:09 -0700 (PDT) Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 9 Jul 2009 14:03:08 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Thu, 9 Jul 2009 14:03:09 -0700 From: "Narayanan, Vidya" To: Eric Rescorla Date: Thu, 9 Jul 2009 14:03:08 -0700 Thread-Topic: [P2PSIP] Client operation in RELOAD Thread-Index: Acn/83bKsY5CD/owRDShSCfqkHqXIQA5KjSw Message-ID: References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> In-Reply-To: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 21:02:49 -0000 I'm not sure I understand what you are saying. Are you saying that an Atta= ch request without a preceding Join is indicative of joining as a client? = If so, a client finds a bootstrap peer and sends an Attach request to its o= wn node id, in order to find the node that it is supposed to attach to? AF= AICT, this doesn't seem to be described in the draft. Even if it is, I don= 't understand how a node differentiates a client from another neighbor, bec= ause treating the client as a neighbor and sending updates to all other nei= ghbors will create an incorrect view of the DHT for the other nodes. If yo= u are saying that all of this is implicit in the fact that an Attach was re= ceived without a Join, it seems setting up for issues. I think it is bette= r off to explicitly join as a client to avoid any ambiguity.=20 It is possible that I misunderstood what you are saying, in which case, ple= ase explain a bit further.=20 Thanks, Vidya=20 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Wednesday, July 08, 2009 10:43 AM > To: Narayanan, Vidya > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Client operation in RELOAD >=20 > At Wed, 1 Jul 2009 12:18:13 -0700, > Narayanan, Vidya wrote: > > The client operation in RELOAD is currently underspecified and > > cannot be implemented based on the spec. >=20 > I'm certainly prepared to believe that's correct, but I'm not really > getting that from your message. From my perspective, the major > feature of the RELOAD client design is that there *isn't* any > special support for clients, but that it just drops out of > the rest of the specified protocol. >=20 >=20 > > Message changes necessary to support clients: > > --------------------------------------------- > > We need to introduce a "Node Type" in the JOIN Request message that > > indicates that the joining node wishes to do so as a client. Also, > > Update messages need to have a "case clients" and the "case full" > > needs to include client information. >=20 > In the current design, clients simply don't send Join or Update, so > this > isn't an issue. Because they don't really participate in either the > storage or routing fabric, as far as I can tell they don't need > to do either. >=20 >=20 > > I suggest adding a section on clients - suggested text below: > > > > Clients: > > -------- > > Clients are nodes that may provide and receive services in an > > overlay without participating in overlay routing or incurring the > > same amount of maintenance overhead as the overlay peers. Clients > > are modeled as close to peers as possible in terms of overlay > > functionality. In order to allow these nodes to participate in the > > overlay without inherently being a routing member of the overlay, > > some changes are required to the join process and the manner in > > which neighbor relationships are handled for such nodes. However, > > all other procedures (e.g., data management using STORE, FETCH, > > etc.) are handled in exactly the same way as for any other peer in > > the overlay. > > > > We denote the point of attachment of the Non-Routing Peer on to the > > overlay as Overlay Attachment Point (OAP). The peer responsible for > > the node ID of the client provides the OAP functionality. This > > allows the integration of clients into the architecture with the > > least deviation from the peer. Hence, any node that wishes to be a > > client finds the node that owns its identity space and attaches to > > it. By definition, any node serving as a peer in the overlay MUST > > provide the OAP functionality as well. The mode of using a > > different node as the OAP may be allowed as an extension to this > > protocol - this can be done for availability or load balancing > > reasons, for instance. > > > > Clients obtain overlay node identities just like peers do. Hence, > > the enrollment server may be completely unaware of the distinction > > between a peer and a client. By virtue of this, the enrollment > > procedure is identical for peers and clients. The join procedure is > > somewhat simplified for a client and the section below describes > > that process. All data management operations to/from a client are > > indistinguishable from those of a peer. > > > > The main difference between a client and a peer is that a client > > only has a single neighbor in the overlay, i.e., the OAP. The > > client routes all messages through the OAP - i.e., it has a default > > route with the OAP as next hop that is used for all messages. The > > OAP has the client as a neighbor and has it in its routing table. > > None of the nodes in the overlay except the OAP are aware of the > > presence of the client. The messages to/from a client are natively > > routed on the overlay. All messages that are sent to the client > > arrive at the OAP by regular overlay routing (since it owns the > > identity space that includes that of the client). The OAP then > > looks up its routing table to route the message to the client. > > > > The OAP may make use of the presence of a client to offload some of > > its storage responsibilities or to replicate data stored at it. > > This may be mutually beneficial in some cases - e.g., the client may > > be limited in terms of bandwidth and battery, while the OAP may be > > limited in memory. However, this is out of scope for this document > > itself and any such storage sharing that occurs between a client and > > OAP is not visible to the rest of the overlay. Hence, any such > > thing must be managed out of band between the OAP and the client. >=20 > I agree with almost all of this text, but it's not normative > and I'm not sure really clarifies things that much. As far as > clients storing data for OAPs goes, IMO that should be out > of scope of the protocol. If clients and OAPs want to design > some new protocol that handles that great, but it's not RELOADs > business. >=20 >=20 > > Client Bootstrap Process: > > ------------------------- > > A client obtains a list of bootstrap peers from the enrollment > > server as any other node in the overlay. The client triggers the > > join process the same way as a peer does. But, the process is a bit > > more abridged than for a normal peer. It is described below: > > > > 1. Client connects to its chosen bootstrap node. The client MUST > > form a TLS session with the bootstrap node, using the certificate or > > PSK required for overlay membership. 2. The client sends a Join > > request message to its own Node-ID c, through the BP. The Join > > Request message indicates that the joining entity is a client (with > > Node Type being set to Client). This is routed to the admitting > > peer (AP). The AP sends a response to the Join, after noting that > > it must serve as the OAP. 3. The client also sends an Attach > > request message to c through the BP. This may be sent in parallel > > with the Join message. The AP sends an Attach response, resulting > > in connection establishment between the client and AP. At this > > point, the AP has the client included in its routing and connection > > tables and the client has established a default route through the > > AP. The join process is now complete. > > > > The OAP MUST NOT send any Update messages to other peers in the > > overlay as a result of a client joining the overlay. The OAP simply > > updates its routing and connection tables with the client > > information. The client does the same. The OAP may, however, > > follow up the join process with a series of STORE request messages > > to transfer some data it stores to the client. >=20 > I disaree with this: the client should not be sending a Join because > that indicates the desire to be a peer. There is no need for the > join as mere attachment enables direct routing to the client > from the OAP. >=20 >=20 > > Impact of Churn on Clients: > > ---------------------------- > > As the ownership of the overlay identity space changes, the clients > > may be affected. For instance, if the OAP to which a client is > > attached leaves the overlay or fails, the client needs to find the > > appropriate OAP to attach to. Also, when the identity ownership > > changes due to a new peer attaching between the OAP and the client > > in the identity space, the client needs to use the new peer as its > > OAP. Essentially, the need to change OAP may arise from one of the > > following three conditions: > > > > * A new peer joined the overlay with an identity that lies between > > * the identities of a client and its OAP > > > > * The OAP of a client performs a graceful leave from the overlay > > > > * The OAP of a client abruptly leaves the overlay or fails > > > > These three cases are explained below. > > > > Handling New Peers: > > ------------------- > > > > Consider the case where a client (C1) is attached to an OAP (OAP1). > > A new peer, P, attaches to the overlay, with an identity that falls > > between C1's and OAP1's identity. P is now responsible for the > > identity that belongs to C1 and hence needs to serve as the OAP to > > C1 (say, OAP2). When P completes its Join process, OAP1 detects > > that it no longer owns the identity corresponding to C1. OAP1 now > > sends an Update message to C1, indicating that it has a new > > neighbor. The Update message provides information about P to C1. > > Upon receiving the Update message, C1 sends a Join Request via OAP1 > > to P. The difference between this JOIN process and the regular one > > is that C1 can perform this Join via OAP1 instead of finding a > > bootstrap peer to perform the join through. Since P is part of the > > overlay and is OAP1's neighbor, OAP1 can reach P directly, thereby > > greatly reducing the number of hops the Join messages need to > > traverse. Once the new Join process completes, P takes over as C1' > > s OAP (OAP2). C1 may send a Leave Request to OAP1 subsequent to > > its attachment to OAP2 - this will trigger cleaning up of state > > corresponding to C1 at OAP1. > > > > If OAP1 stored any of its data at C1, C1 must transfer that back to > > OAP1 before joining again with OAP2. The mechanism to handle this > > is out of scope of this specification. > > > > When a change in the identity space ownership causes the OAP of a > > particular node to change, the present OAP MUST send an Update > > message to the client, indicating that it has a new neighbor. Upon > > receiving the update message, the client MUST send a Join message to > > the new OAP - this JOIN message can be routed through its current > > OAP. The client SHOULD send a Leave request to its old OAP, once it > > has successfully attached to the new OAP. >=20 > In general, whenever a peer's view of its neighbor changes it > should Update all its neighbors. As "client" isn't a first-class > term in RELOAD, this implies clients as well. I agree we should > explicitly state that clients need to disconnect and reconnect > to the new responsible peer. As indicated above, I believe the > discussion of Join is incorrect. >=20 >=20 > > There is an issue that nodes may send attach messages to the > > client's node id when looking for a finger. The client needs to > > reject such Attach requests coming to it. However, the client will > > be unable to distinguish Attach messages that are being sent to it > > to really set up an end-to-end connection for other purposes. We > > may want to consider introducing a "purpose" in the Attach request > > messages that indicate the reason for the Attach. This will make it > > possible for the client to reject a request that is sent to > > establish a finger. The node sending the Attach request can then > > slightly alter the resource id to issue another request. >=20 > There is supposed to be an AppAttach message that makes this > clear. It just somehow didn't make it into the draft. It will > be in the next revision. >=20 > -Ekr From julian@orchidseed.org Thu Jul 9 20:55:10 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9125A3A69CC for ; Thu, 9 Jul 2009 20:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD8ZdAYNHOdE for ; Thu, 9 Jul 2009 20:55:09 -0700 (PDT) Received: from mail-yx0-f180.google.com (mail-yx0-f180.google.com [209.85.210.180]) by core3.amsl.com (Postfix) with ESMTP id 4F7F83A68B7 for ; Thu, 9 Jul 2009 20:55:09 -0700 (PDT) Received: by yxe10 with SMTP id 10so1200258yxe.29 for ; Thu, 09 Jul 2009 20:55:35 -0700 (PDT) Received: by 10.90.26.3 with SMTP id 3mr1287817agz.27.1247198135312; Thu, 09 Jul 2009 20:55:35 -0700 (PDT) Received: from ?10.0.1.2? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 20sm1704824agb.25.2009.07.09.20.55.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Jul 2009 20:55:34 -0700 (PDT) Message-Id: From: Julian Cain To: Peter Slow In-Reply-To: <53fc16d40907090710n5e67dfd3j2191a15c0a5e72b0@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-3-455475748 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 20:55:31 -0700 References: <53fc16d40907090710n5e67dfd3j2191a15c0a5e72b0@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Hello Everyone X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 03:55:10 -0000 --Apple-Mail-3-455475748 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Pete, I hail from Kazaa the Pre-curser to Skype and then many years later worked for SIPphone on the Gizmo Project SIP stack and client. The idea of P2PSIP is an old idea, take Skype and remove SKYLIB but retain the Overlay routing layer and replace it with SIP, then pretend the back end is all SIP based including registrar, etc. I have had the Nyquil stare when I started coding and discussing ICE, Overlay's, DHT's, etc for use with SIP some 3 years ago to Internal people as well as people from Adobe and Nokia and here we are now, oh the irony. :-) A non-p2p based SIP network technically cannot scale upwards of 2 ^ 128 - 1 assuming IPv6 without a linear increase of dedicated hardware and humans for call routing. jc On Jul 9, 2009, at 7:10 AM, Peter Slow wrote: > Hi there, > My name is Pete and I heard about P2P SIP at a (SIP Specific, not > vendor-specific) "Advancements in SIP" session at Cisco live this past > week. As someone who has done ridiculous amounts of CallManager > configuration and troubleshooting, coming from a routing and switching > background, the fact that I have to deal with troubleshooting call > routing loops has always bothered me. > Why should I have to go to clusters of callmanagers or other h.323 > or SIP entities, all integrated with each other, and configure what > are essentially static routes on them, pointing number patterns at the > appropriate entities? I asked this question of some people while I was > at TAC and they looked at me like I'd had too much NyQuil. Devices > know what DNs are on them, and call processing entities know what > patterns are configured for access to local gateways... Why do I need > to go to other entities and configure these patterns etc repeatedly? > Why can't they just tell each other? This has always seemed > sub-optimal and inefficient to me. > This is my understanding of what P2P SIP is meant to help with or > do, and I would like to contribute thoughts and ideas from the > perspective of someone whose done lots of both voice and routing and > switching design and integration =) ...I'd like to not have to > configure route patterns more than once. In my humble opinion, > afterwards, some sort of routing protocol should take care of telling > other clusters and entities about patterns and devices and RP-ish > things like split-horizon should be used to make sure that we don't > create call routing loops by sending calls back to where they > originated from. (with minor exceptions for certain callflows.) > > Nice to meet you all, > Peter > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-3-455475748 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Pete,
I hail from Kazaa = the Pre-curser to Skype and then many years later worked for SIPphone on = the Gizmo Project SIP stack and client.

The = idea of P2PSIP is an old idea, take Skype and remove SKYLIB but retain = the Overlay routing layer and replace it with SIP, then pretend the back = end is all SIP based including registrar, etc. I have had the Nyquil = stare when I started coding and discussing ICE, Overlay's, DHT's, etc = for use with SIP some 3 years ago to Internal people as well as people = from Adobe and Nokia and here we are now, oh the irony. = :-)

A non-p2p based SIP network technically = cannot scale upwards of 2 ^ 128 - 1 assuming IPv6 without a linear = increase of dedicated hardware and humans for call = routing.

jc

On Jul 9, = 2009, at 7:10 AM, Peter Slow wrote:

Hi = there,
  My name is Pete and I heard about P2P SIP at a = (SIP Specific, not
vendor-specific) "Advancements in SIP" session at = Cisco live this past
week. As someone who has done ridiculous amounts = of CallManager
configuration and troubleshooting, coming from a = routing and switching
background, the fact that I have to deal with = troubleshooting call
routing loops has always bothered = me.
  Why should I have to go to clusters of callmanagers = or other h.323
or SIP entities, all integrated with each other, and = configure what
are essentially static routes on them, pointing number = patterns at the
appropriate entities? I asked this question of some = people while I was
at TAC and they looked at me like I'd had too much = NyQuil. Devices
know what DNs are on them, and call processing = entities know what
patterns are configured for access  to local = gateways... Why do I need
to go to other entities and configure these = patterns etc repeatedly?
Why can't they just tell each other? This = has always seemed
sub-optimal and inefficient to = me.
  This is my understanding of what P2P SIP is meant to = help with or
do, and I would like to contribute thoughts and ideas = from the
perspective of someone whose done lots of both voice and = routing and
switching design and integration =3D) ...I'd like to not = have to
configure route patterns more than once. In my humble = opinion,
afterwards, some sort of routing protocol should take care = of telling
other clusters and entities about patterns and devices and = RP-ish
things like split-horizon should be used to make sure that we = don't
create call routing loops by sending calls back to where = they
originated from. (with minor exceptions for certain = callflows.)

Nice to meet you = all,
  Peter
_____________________________________________= __
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail-3-455475748-- From julian@orchidseed.org Thu Jul 9 21:14:18 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1FE3A6CAF for ; Thu, 9 Jul 2009 21:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQmhc6gxE-L7 for ; Thu, 9 Jul 2009 21:14:17 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id DC03E3A6CBB for ; Thu, 9 Jul 2009 21:14:08 -0700 (PDT) Received: by gxk26 with SMTP id 26so1123672gxk.13 for ; Thu, 09 Jul 2009 21:14:35 -0700 (PDT) Received: by 10.90.120.14 with SMTP id s14mr1305111agc.51.1247199274935; Thu, 09 Jul 2009 21:14:34 -0700 (PDT) Received: from ?10.0.1.2? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 32sm1930952aga.4.2009.07.09.21.14.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Jul 2009 21:14:34 -0700 (PDT) Message-Id: From: Julian Cain To: "Narayanan, Vidya" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 21:14:30 -0700 References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> X-Mailer: Apple Mail (2.935.3) Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 04:14:18 -0000 On Jul 9, 2009, at 2:03 PM, Narayanan, Vidya wrote: > I'm not sure I understand what you are saying. Are you saying that > an Attach request without a preceding Join is indicative of joining > as a client? If so, a client finds a bootstrap peer and sends an > Attach request to its own node id, in order to find the node that it > is supposed to attach to? AFAICT, this doesn't seem to be described > in the draft. Even if it is, I don't understand how a node > differentiates a client from another neighbor, because treating the > client as a neighbor and sending updates to all other neighbors will > create an incorrect view of the DHT for the other nodes. None of this is defined in the draft, only indications of "Client Operation" thus the controversy of Client Join vs. Peer Join will continue to be debated for now. > If you are saying that all of this is implicit in the fact that an > Attach was received without a Join, it seems setting up for issues. > I think it is better off to explicitly join as a client to avoid any > ambiguity. IMHO: You SHOULD perform a Join as a Client and then if need be Join as a Peer. You'd have to first Join and Lookup where you belong in the ring and then re-join at that node-id to avoid ring imbalance. > > It is possible that I misunderstood what you are saying, in which > case, please explain a bit further. > > Thanks, > Vidya > >> -----Original Message----- >> From: Eric Rescorla [mailto:ekr@networkresonance.com] >> Sent: Wednesday, July 08, 2009 10:43 AM >> To: Narayanan, Vidya >> Cc: p2psip@ietf.org >> Subject: Re: [P2PSIP] Client operation in RELOAD >> >> At Wed, 1 Jul 2009 12:18:13 -0700, >> Narayanan, Vidya wrote: >>> The client operation in RELOAD is currently underspecified and >>> cannot be implemented based on the spec. >> >> I'm certainly prepared to believe that's correct, but I'm not really >> getting that from your message. From my perspective, the major >> feature of the RELOAD client design is that there *isn't* any >> special support for clients, but that it just drops out of >> the rest of the specified protocol. >> >> >>> Message changes necessary to support clients: >>> --------------------------------------------- >>> We need to introduce a "Node Type" in the JOIN Request message that >>> indicates that the joining node wishes to do so as a client. Also, >>> Update messages need to have a "case clients" and the "case full" >>> needs to include client information. >> >> In the current design, clients simply don't send Join or Update, so >> this >> isn't an issue. Because they don't really participate in either the >> storage or routing fabric, as far as I can tell they don't need >> to do either. >> >> >>> I suggest adding a section on clients - suggested text below: >>> >>> Clients: >>> -------- >>> Clients are nodes that may provide and receive services in an >>> overlay without participating in overlay routing or incurring the >>> same amount of maintenance overhead as the overlay peers. Clients >>> are modeled as close to peers as possible in terms of overlay >>> functionality. In order to allow these nodes to participate in the >>> overlay without inherently being a routing member of the overlay, >>> some changes are required to the join process and the manner in >>> which neighbor relationships are handled for such nodes. However, >>> all other procedures (e.g., data management using STORE, FETCH, >>> etc.) are handled in exactly the same way as for any other peer in >>> the overlay. >>> >>> We denote the point of attachment of the Non-Routing Peer on to the >>> overlay as Overlay Attachment Point (OAP). The peer responsible for >>> the node ID of the client provides the OAP functionality. This >>> allows the integration of clients into the architecture with the >>> least deviation from the peer. Hence, any node that wishes to be a >>> client finds the node that owns its identity space and attaches to >>> it. By definition, any node serving as a peer in the overlay MUST >>> provide the OAP functionality as well. The mode of using a >>> different node as the OAP may be allowed as an extension to this >>> protocol - this can be done for availability or load balancing >>> reasons, for instance. >>> >>> Clients obtain overlay node identities just like peers do. Hence, >>> the enrollment server may be completely unaware of the distinction >>> between a peer and a client. By virtue of this, the enrollment >>> procedure is identical for peers and clients. The join procedure is >>> somewhat simplified for a client and the section below describes >>> that process. All data management operations to/from a client are >>> indistinguishable from those of a peer. >>> >>> The main difference between a client and a peer is that a client >>> only has a single neighbor in the overlay, i.e., the OAP. The >>> client routes all messages through the OAP - i.e., it has a default >>> route with the OAP as next hop that is used for all messages. The >>> OAP has the client as a neighbor and has it in its routing table. >>> None of the nodes in the overlay except the OAP are aware of the >>> presence of the client. The messages to/from a client are natively >>> routed on the overlay. All messages that are sent to the client >>> arrive at the OAP by regular overlay routing (since it owns the >>> identity space that includes that of the client). The OAP then >>> looks up its routing table to route the message to the client. >>> >>> The OAP may make use of the presence of a client to offload some of >>> its storage responsibilities or to replicate data stored at it. >>> This may be mutually beneficial in some cases - e.g., the client may >>> be limited in terms of bandwidth and battery, while the OAP may be >>> limited in memory. However, this is out of scope for this document >>> itself and any such storage sharing that occurs between a client and >>> OAP is not visible to the rest of the overlay. Hence, any such >>> thing must be managed out of band between the OAP and the client. >> >> I agree with almost all of this text, but it's not normative >> and I'm not sure really clarifies things that much. As far as >> clients storing data for OAPs goes, IMO that should be out >> of scope of the protocol. If clients and OAPs want to design >> some new protocol that handles that great, but it's not RELOADs >> business. >> >> >>> Client Bootstrap Process: >>> ------------------------- >>> A client obtains a list of bootstrap peers from the enrollment >>> server as any other node in the overlay. The client triggers the >>> join process the same way as a peer does. But, the process is a bit >>> more abridged than for a normal peer. It is described below: >>> >>> 1. Client connects to its chosen bootstrap node. The client MUST >>> form a TLS session with the bootstrap node, using the certificate or >>> PSK required for overlay membership. 2. The client sends a Join >>> request message to its own Node-ID c, through the BP. The Join >>> Request message indicates that the joining entity is a client (with >>> Node Type being set to Client). This is routed to the admitting >>> peer (AP). The AP sends a response to the Join, after noting that >>> it must serve as the OAP. 3. The client also sends an Attach >>> request message to c through the BP. This may be sent in parallel >>> with the Join message. The AP sends an Attach response, resulting >>> in connection establishment between the client and AP. At this >>> point, the AP has the client included in its routing and connection >>> tables and the client has established a default route through the >>> AP. The join process is now complete. >>> >>> The OAP MUST NOT send any Update messages to other peers in the >>> overlay as a result of a client joining the overlay. The OAP simply >>> updates its routing and connection tables with the client >>> information. The client does the same. The OAP may, however, >>> follow up the join process with a series of STORE request messages >>> to transfer some data it stores to the client. >> >> I disaree with this: the client should not be sending a Join because >> that indicates the desire to be a peer. There is no need for the >> join as mere attachment enables direct routing to the client >> from the OAP. >> >> >>> Impact of Churn on Clients: >>> ---------------------------- >>> As the ownership of the overlay identity space changes, the clients >>> may be affected. For instance, if the OAP to which a client is >>> attached leaves the overlay or fails, the client needs to find the >>> appropriate OAP to attach to. Also, when the identity ownership >>> changes due to a new peer attaching between the OAP and the client >>> in the identity space, the client needs to use the new peer as its >>> OAP. Essentially, the need to change OAP may arise from one of the >>> following three conditions: >>> >>> * A new peer joined the overlay with an identity that lies between >>> * the identities of a client and its OAP >>> >>> * The OAP of a client performs a graceful leave from the overlay >>> >>> * The OAP of a client abruptly leaves the overlay or fails >>> >>> These three cases are explained below. >>> >>> Handling New Peers: >>> ------------------- >>> >>> Consider the case where a client (C1) is attached to an OAP (OAP1). >>> A new peer, P, attaches to the overlay, with an identity that falls >>> between C1's and OAP1's identity. P is now responsible for the >>> identity that belongs to C1 and hence needs to serve as the OAP to >>> C1 (say, OAP2). When P completes its Join process, OAP1 detects >>> that it no longer owns the identity corresponding to C1. OAP1 now >>> sends an Update message to C1, indicating that it has a new >>> neighbor. The Update message provides information about P to C1. >>> Upon receiving the Update message, C1 sends a Join Request via OAP1 >>> to P. The difference between this JOIN process and the regular one >>> is that C1 can perform this Join via OAP1 instead of finding a >>> bootstrap peer to perform the join through. Since P is part of the >>> overlay and is OAP1's neighbor, OAP1 can reach P directly, thereby >>> greatly reducing the number of hops the Join messages need to >>> traverse. Once the new Join process completes, P takes over as C1' >>> s OAP (OAP2). C1 may send a Leave Request to OAP1 subsequent to >>> its attachment to OAP2 - this will trigger cleaning up of state >>> corresponding to C1 at OAP1. >>> >>> If OAP1 stored any of its data at C1, C1 must transfer that back to >>> OAP1 before joining again with OAP2. The mechanism to handle this >>> is out of scope of this specification. >>> >>> When a change in the identity space ownership causes the OAP of a >>> particular node to change, the present OAP MUST send an Update >>> message to the client, indicating that it has a new neighbor. Upon >>> receiving the update message, the client MUST send a Join message to >>> the new OAP - this JOIN message can be routed through its current >>> OAP. The client SHOULD send a Leave request to its old OAP, once it >>> has successfully attached to the new OAP. >> >> In general, whenever a peer's view of its neighbor changes it >> should Update all its neighbors. As "client" isn't a first-class >> term in RELOAD, this implies clients as well. I agree we should >> explicitly state that clients need to disconnect and reconnect >> to the new responsible peer. As indicated above, I believe the >> discussion of Join is incorrect. >> >> >>> There is an issue that nodes may send attach messages to the >>> client's node id when looking for a finger. The client needs to >>> reject such Attach requests coming to it. However, the client will >>> be unable to distinguish Attach messages that are being sent to it >>> to really set up an end-to-end connection for other purposes. We >>> may want to consider introducing a "purpose" in the Attach request >>> messages that indicate the reason for the Attach. This will make it >>> possible for the client to reject a request that is sent to >>> establish a finger. The node sending the Attach request can then >>> slightly alter the resource id to issue another request. >> >> There is supposed to be an AppAttach message that makes this >> clear. It just somehow didn't make it into the draft. It will >> be in the next revision. >> >> -Ekr > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Fri Jul 10 11:01:20 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E3328C37E for ; Fri, 10 Jul 2009 11:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2-EvU9e-ovc for ; Fri, 10 Jul 2009 11:01:19 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id CE2A328C37D for ; Fri, 10 Jul 2009 11:01:18 -0700 (PDT) Received: by fxm18 with SMTP id 18so1054080fxm.37 for ; Fri, 10 Jul 2009 11:01:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.112.130 with SMTP id w2mr1263029fap.65.1247248904743; Fri, 10 Jul 2009 11:01:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Jul 2009 14:01:44 -0400 Message-ID: From: Bruce Lowekamp To: "Narayanan, Vidya" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Section 9 of RELOAD - Comments X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:01:20 -0000 The next revision should address the issues raised in this thread. A couple responses inline. 2009/5/11 Bruce Lowekamp : >> =C2=A0 "Note that a malicious node can return a success response but not >> =C2=A0 store the data locally or in the replica set. =C2=A0Requesting pe= ers that >> =C2=A0 wish to ensure that the replication actually occurred SHOULD [[Op= en >> =C2=A0 Issue: =C2=A0SHOULD or MAY?]] contact each peer listed in the rep= licas >> =C2=A0 field of the Store response and retrieve a copy of the data." >> >> The above text is not just relevant for redundant copies of data stored = - it is true for even the actual resource-id owner. =C2=A0Also, in light of= not waiting for the replica responses, the STORE response will not contain= a list of replicas - so, this needs to be corrected. >> > > Yes, that last text doesn't apply just to replicas. =C2=A0Will reword. > > The responsible peer can, however, include the peerids of the peers on > which it will place replicas, even if it doesn't wait to confirm their > responses. > I think it's a bit too much to cover that issue in that section, and the real issue (and defense) is already in the security section. Instead, the text here now reads: The sequential replicas used in this overlay algorithm protect against peer failure but not against subversive peers. Additional replication from the Usage is required to protect resources from such attacks, as discussed in >> Joining (Section 9.5): >> ---------------------- >> It is not clear why the join procedure requires all neighbor and finger = connections to be established prior to sending the JOIN message itself. =C2= =A0To be functional in the overlay, only the immediate successor relationsh= ips must be correctly in place. =C2=A0The other successors, predecessors an= d fingers can be established subsequently. =C2=A0This also doesn't cause no= des to establish unnecessary connections unless the node has successfully j= oined. =C2=A0There is also the question of whether a JP is supposed to esta= blish a TLS connection to the BP to send messages through it, which is pres= ently not addressed in the draft. =C2=A0It seems to me that a more streamli= ned join process can be defined as follows: >> > > You're right that it's just an optimization to have finger table > entries, but it's not completely clear to me that adding a new peer > without finger table entries provides a benefit to the overlay. =C2=A0I c= an > see that being a SHOULD, though. > Strictly speaking, the algorithm describing joining is not written in normative language. We need a full pass over the entire doc to figure out what needs to be normative and what doesn't, and this is definitely one of those places where some of it needs to be normative. What I did for now, however, was add a paragraph that says the JP MUST NOT send an Update placing itself in the overlay until it has Attached to all of the peers in its neighbor table. That's the real MUST requirement, and while I still believe it's better to do it in the order described currently, it allows other implementations if there is a motivation for them. >> Updates (Section 9.7): >> ---------------------- >> Section 9.7.1. states that every time a connection is lost, the peer sho= uld remove it from its neighbor table and find a different peer. =C2=A0Sect= ion 9.7.3. talks about attempting to re-establish connections when a neighb= or is detected to be invalid. =C2=A0These are at odds. =C2=A0It seems to ma= ke sense that the peer would always try to re-establish connections and onl= y remove that neighbor if the connection cannot be re-established. >> > > Working on some new text along these lines for the next revision. > The text in 9.7.3 didn't belong there. I removed that, renamed 9.7.1 to describe handling neighbor failure and added a new section on handling finger table entry failures. Along with that, some new text was added that says a peer MAY re-establish connections, but it's not required to do so. The sections were also reworded slightly to make the reactive behavior optional. They now say "if using reactive recovery..." >> Finger entries (Section 9.7.3 and elsewhere): >> --------------------------------------------- >> The draft requires 16 finger table entries - at first, I took those to m= ean 16 different resource ids that will be probed per formula. =C2=A0After = reading 9.7.3, it appears that it is talking about 16 different fingers tha= t a node should maintain. =C2=A0In a small overlay, that's ridiculously lar= ge. =C2=A0The text is also unclear on what happens when the overlay shrinks= . =C2=A0Further, the text states that a peer SHOULD consider the finger tab= le entry valid if it is in the range [n + 2^(numBitsInNodeId-i), n + 1.5 x = 2^(numBitsInNodeId-i)]. For small overlays, there may be no entries in this= range for every i in [0, 127]. >> > > The text was left the way it is in an effort to make it simpler, but I > think there may be an issue in there where too many MUSTs are > prohibiting common optimizations. =C2=A0Definitely need to take a look at > that. =C2=A0I think the right answer here is to check the existing text f= or > being too pedantic and compare its length & complexity with the > optimization you describe (which I agree is how this should really be > implemented). > > >> A node should only need log N fingers to route in OlogN hops. =C2=A0What= we need to specify is an algorithm that uses the same pattern in resource = ids to probe - the fingers corresponding to multiple of those will collapse= to the same node in a small overlay. =C2=A0In our implementation, the algo= rithm works as follows: >> >> A node looks at the list of resource-ids corresponding to f=3D(n+2^i), f= or all values of i=3D[0,127]. =C2=A0Let's say that it first probes n+2^0 an= d obtains a finger of f0. =C2=A0It checks f0 against the next set of resour= ce-ids to probe and determines the next larger resource-id to probe from th= e list. =C2=A0It populates the finger table entries for all other fingers f= for which n < f < f0, with f0 as the corresponding finger. =C2=A0Depending= on the number of nodes in the overlay, this should result in approximately= logN fingers in the finger table at any time. =C2=A0Periodic stabilization= should adjust the number of fingers automatically. =C2=A0In fact, the numb= er of fingers a node has should provide a rough estimate (with accuracy in = the order of log N) of the size of the overlay. =C2=A0The current text sugg= ests that the number of fingers should be decided based on the overlay size= , which does not seem intuitive or necessary. >> OK, so after reading this closer, you're not describing what I thought. First, it's a bit confusing since the draft indexes the finger table entries backwards so that finger[0] is halfway around the overlay. That's not how it's done in the original Chord paper, but it makes it a lot easier to think about variable size finger tables. Secondly, we need to limit the amount of traffic this produces and time it takes. I'm not convinced that walking through the finger table space is a good idea, even though obviously you'll skip a lot of potential slots. To try to improve this section, I've made these changes: - I realized that the stabilization section said that updates are sent to all peers in the routing table. Should have been neighbor table. Though there - Suggest a couple approaches to identifying which peers to Probe for new finger table entries, but leave this mostly tunable. I completely rewrote much of this section to make it more readable. Bruce From ekr@networkresonance.com Fri Jul 10 13:21:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A243A6E7B for ; Fri, 10 Jul 2009 13:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZNqYAUA7Mwi for ; Fri, 10 Jul 2009 13:21:30 -0700 (PDT) Received: from kilo.networkresonance.com (dhcp-128-107-47-96.cisco.com [128.107.47.96]) by core3.amsl.com (Postfix) with ESMTP id 0F11E3A6E7C for ; Fri, 10 Jul 2009 13:21:30 -0700 (PDT) Received: from dhcp-128-107-47-96.cisco.com (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 388F01CAFC7; Fri, 10 Jul 2009 13:23:07 -0700 (PDT) Date: Fri, 10 Jul 2009 13:23:07 -0700 From: Eric Rescorla To: "Narayanan, Vidya" In-Reply-To: References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090710202307.388F01CAFC7@kilo.networkresonance.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:21:31 -0000 At Thu, 9 Jul 2009 14:03:08 -0700, Narayanan, Vidya wrote: > > I'm not sure I understand what you are saying. Are you saying that > an Attach request without a preceding Join is indicative of joining > as a client? No, I'm saying that "client" isn't a first class concept in RELOAD. The generic procedures defined in RELOAD make peers handle client nodes correctly automatically. So, all that's required is that nodes which wish not to be part of the routing fabric and storage fabric not send the messages that would make them so. > If so, a client finds a bootstrap peer and sends an > Attach request to its own node id, in order to find the node that it > is supposed to attach to? Yes. > AFAICT, this doesn't seem to be described > in the draft. That's because there is no new normative behavior. Clients simply don't send Join or Update. > Even if it is, I don't understand how a node > differentiates a client from another neighbor, because treating the > client as a neighbor and sending updates to all other neighbors will > create an incorrect view of the DHT for the other nodes. If you are > saying that all of this is implicit in the fact that an Attach was > received without a Join, it seems setting up for issues. I think it > is better off to explicitly join as a client to avoid any ambiguity. A node doesn't know that an adjacency is a client or not. What it knows is that it's a node that hasn't sent any Updates and therefore shouldn't be advertised to other nodes in the overlay. It could be a client or it could be a node which just hasn't sent any Updates or Joins yet (but will eventually). It doesn't matter. This is a feature of the design, not a bug. -Ekr From hardie@qualcomm.com Fri Jul 10 15:03:37 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AB1F28C38D for ; Fri, 10 Jul 2009 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDLXwAmMT5cw for ; Fri, 10 Jul 2009 15:03:36 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6B18A28C30E for ; Fri, 10 Jul 2009 15:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1247263445; x=1278799445; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<20090710202307.388F01CAF C7@kilo.networkresonance.com>|References:=20=0D=0A=20<20090708174319.E696A1C7B5B@kilo.networkresona nce.com>=0D=0A=20=0D=0A=20<20090710202307. 388F01CAFC7@kilo.networkresonance.com>|Date:=20Fri,=2010 =20Jul=202009=2015:04:01=20-0700|To:=20Eric=20Rescorla=20 ,=0D=0A=20=20=20=20=20=20=20=20 "Narayanan,=20Vidya"=0D=0A=09|From: =20Ted=20Hardie=20|Subject:=20Re:=20 [P2PSIP]=20Client=20operation=20in=20RELOAD|CC:=20"p2psip @ietf.org"=20|Content-Type:=20text/plain =3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3B i=3D"5300,2777,5672"=3B=20a=3D"20562971"; bh=8yg70arYN5JSfZpxz+xHn9k9gUGvzN6pQgveNGQEQ70=; b=lvYMcg8hFaydFDpB4yAre24/2M/rPhscfpPYHNASy/pTGGw5Hmnn6GIa iBIg74e7JMFBtrIVTVtJlr6G4ODb+uGn4cS3wVZ6PnreaIY8qjP8Rlxbn CaPRUCxcsXLz+YorPu4inJTZgHpIAyGcRWRxXAmFUVwLpFD8UQWFZXnyb c=; X-IronPort-AV: E=McAfee;i="5300,2777,5672"; a="20562971" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2009 15:04:04 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6AM4421012941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Jul 2009 15:04:04 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6AM44nq012092 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Jul 2009 15:04:04 -0700 (PDT) Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 10 Jul 2009 15:04:03 -0700 Received: from [10.227.68.80] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 10 Jul 2009 15:04:03 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <20090710202307.388F01CAFC7@kilo.networkresonance.com> References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> Date: Fri, 10 Jul 2009 15:04:01 -0700 To: Eric Rescorla , "Narayanan, Vidya" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 22:03:37 -0000 At 1:23 PM -0700 7/10/09, Eric Rescorla wrote: >At Thu, 9 Jul 2009 14:03:08 -0700, >Narayanan, Vidya wrote: >> >> I'm not sure I understand what you are saying. Are you saying that >> an Attach request without a preceding Join is indicative of joining >> as a client? > >No, I'm saying that "client" isn't a first class concept in RELOAD. >The generic procedures defined in RELOAD make peers handle client >nodes correctly automatically. So, all that's required is that >nodes which wish not to be part of the routing fabric and >storage fabric not send the messages that would make them >so. So, my personal preference is for "client" to be closer to a first class concept, so that this behavior is explicit. That might take the form of a different message after attach. That's largely a style, thing, though, and I agree that the behavior you describe works. But see below. > > >> If so, a client finds a bootstrap peer and sends an >> Attach request to its own node id, in order to find the node that it >> is supposed to attach to? > >Yes. > > >> AFAICT, this doesn't seem to be described >> in the draft. > >That's because there is no new normative behavior. Clients simply >don't send Join or Update. > > >> Even if it is, I don't understand how a node >> differentiates a client from another neighbor, because treating the >> client as a neighbor and sending updates to all other neighbors will >> create an incorrect view of the DHT for the other nodes. If you are >> saying that all of this is implicit in the fact that an Attach was >> received without a Join, it seems setting up for issues. I think it >> is better off to explicitly join as a client to avoid any ambiguity. > >A node doesn't know that an adjacency is a client or not. What it >knows is that it's a node that hasn't sent any Updates and therefore >shouldn't be advertised to other nodes in the overlay. It could >be a client or it could be a node which just hasn't sent any >Updates or Joins yet (but will eventually). It doesn't matter. This is >a feature of the design, not a bug. My concern here is that without an explicit step, some set of implementations may treat long post-Attach periods without joins or updates as indicative that the relationship to the attached node is not healthy. That might take the form of timeouts or something similar. You can retain the current theory and avoid that ambiguity by making the theory you've articulated in this email explicit in the text. That would require some additional verbiage, but it should not require anyone to actually change code. For the folks who implement post-WG discussion, that kind of breadcrumb will be pretty important. My two cents, Ted > >-Ekr >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Fri Jul 10 15:04:58 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C5F3A6804 for ; Fri, 10 Jul 2009 15:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGowj5Eftf24 for ; Fri, 10 Jul 2009 15:04:57 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 494913A67E4 for ; Fri, 10 Jul 2009 15:04:57 -0700 (PDT) Received: by bwz25 with SMTP id 25so1159982bwz.37 for ; Fri, 10 Jul 2009 15:05:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.136 with SMTP id a8mr1335696faq.101.1247263523062; Fri, 10 Jul 2009 15:05:23 -0700 (PDT) In-Reply-To: <20090710202307.388F01CAFC7@kilo.networkresonance.com> References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> Date: Fri, 10 Jul 2009 18:05:23 -0400 Message-ID: From: Bruce Lowekamp To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 22:04:58 -0000 On Fri, Jul 10, 2009 at 4:23 PM, Eric Rescorla wr= ote: >> =C2=A0Even if it is, I don't understand how a node >> differentiates a client from another neighbor, because treating the >> client as a neighbor and sending updates to all other neighbors will >> create an incorrect view of the DHT for the other nodes. If you are >> saying that all of this is implicit in the fact that an Attach was >> received without a Join, it seems setting up for issues. =C2=A0I think i= t >> is better off to explicitly join as a client to avoid any ambiguity. > > A node doesn't know that an adjacency is a client or not. What it > knows is that it's a node that hasn't sent any Updates and therefore > shouldn't be advertised to other nodes in the overlay. It could > be a client or it could be a node which just hasn't sent any > Updates or Joins yet (but will eventually). It doesn't matter. This is > a feature of the design, not a bug. I agree that a feature of the design is that Attach doesn't require a specification of what it's being used for---which allows an implementation to Attach to the responsible peer as an optimization for resource refreshes, for example, without a change in the spec to allow it. The same feature can also be used by clients to support their operation. But I think it's also true that there is relatively little support should any of these Attaches need to migrate to another peer, regardless of whether the Attaching node is a client or peer. I think that making sure we have this feature (or ensuring that it works appropriately via sending Updates to all Attached nodes) would help both client and peer operation. That seems like it's useful in the base spec. More details of how clients might work I think should be in another draft. For example, client might achieve reliable connections via maintaining a link with their responsible peer and its two successors, then conduct appropriate maintenance on these in the event of topology changes. I would like for the base draft to allow the features to implement this, but would rather not make the base draft any more complicated by adding details of how to manage such support. I could see an argument for different ways of handling clients using the same basic mechanisms. Bruce From fluffy@cisco.com Fri Jul 10 15:55:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EC03A6E84 for ; Fri, 10 Jul 2009 15:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.013 X-Spam-Level: X-Spam-Status: No, score=-104.013 tagged_above=-999 required=5 tests=[AWL=-2.464, BAYES_50=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beytfARloMBv for ; Fri, 10 Jul 2009 15:55:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 009923A6E61 for ; Fri, 10 Jul 2009 15:55:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFdkV0qrR7PD/2dsb2JhbAC3BYgjkHEFgS2CG0CBQA X-IronPort-AV: E=Sophos;i="4.42,380,1243814400"; d="scan'208";a="185005607" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2009 22:56:20 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6AMuKgZ019943; Fri, 10 Jul 2009 15:56:20 -0700 Received: from dhcp-171-68-21-42.cisco.com (dhcp-171-68-21-42.cisco.com [171.68.21.42]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6AMuKvW024195; Fri, 10 Jul 2009 22:56:20 GMT Message-Id: <83968E28-0B1B-4EAA-A380-B379929D47AF@cisco.com> From: Cullen Jennings To: JeffreyHo In-Reply-To: Content-Type: text/plain; charset=BIG5; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 15:56:20 -0700 References: X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4048; t=1247266580; x=1248130580; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20=20question=20about=20discov ery=20through=20enrollment=20server |Sender:=20; bh=oIKWRTlD3Mt9zlsW+e8T7HXTfZEGX0OBlZlF99JcxHA=; b=BQyl67scbaYebD5bm5OdGGdyHgtFiyVKwb03KRjKG+Crl34JwPOAcJpwL6 6YBfcnbGgrOqIOiYhyXMfGlsnSmQfukkRerbWYxHEiyB0+bHUcJS2UycaPzr Z7o+EpsfsW; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: p2psip@ietf.org Subject: Re: [P2PSIP] question about discovery through enrollment server X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 22:55:53 -0000 Hi, These are good points thanks you. I tried to clarify the algorithm in =20= the next version of the draft. I'm proposing the text The node first determines the overlay name. This value is provided by the user or some other out of band provisioning mechanism. The out of band mechanisms may also provide an optional URL to the enrollment server but this is NOT RECOMMENDED. If a URL to the enrollment server is not provided, the node MUST do a DNS SRV query using a Service name of "p2p_enroll" and a protocol of tcp to find =20= an enrollment server and form the URL by appending a path of "/p2psip/ enroll" to the overlay name. For example, if the overlay name was example.com, the URL would be "https://example.com/p2psip/enroll". Once an address and URL for the enrollment servers is determined, =20= the peer forms an HTTPS connection to that IP address. The certificate MUST match the overlay name as described in [RFC2818]. Then the =20 node MUST fetch a new copy of the configuration file. To do this, the peer performs a GET to the URL. The result of the HTTP GET is an =20= XML configuration file described above, which replaces any previously learned configuration file for this overlay. On May 4, 2009, at 1:15 , JeffreyHo wrote: > Dear all, > > I have some questions about the content of 10.2 discovery through =20 > enrollment server in RELOAD Base. Could someone please give me answer? > > (1) According to the following paragraphs in 10.2. Discovery =20 > Through Enrollment Server, > > The peer first determines the overlay name. This value is provided > by the user or some other out of band provisioning mechanism. > If the name is an IP address, that is directly used otherwise the =20= > peer > MUST do a DNS SRV query using a Service name of "p2p_enroll" and > a protocol of tcp to find an enrollment server. > > Is the overlay name here equivalent to the attribute 'instance-name' =20= > in the overlay configuration? If yes, but why this paragraph say " =20 > If the name is an IP address, that is directly used "? It seems the =20= > name means the location of the enrollment server not overlay =20 > instance-name. It makes me confused. > > (2) According to 10.1. Overlay Configuration, it said that The file =20= > can contain multiple "configuration" elements where each one =20 > contains the configuration information for a different overlay. In =20= > addition, in 10.2. Discovery Through Enrollment Server, it said =20 > that the peer performs a GET to the URL formed by appending a path =20 > of "/p2psip/enroll" to the overlay name. For example, if the =20 > overlay name was example.com, the URL would be = "https://example.com/p2psip/enroll=20 > ". > > My question is below. > If an single enrollment server maintains two different overlays, =20 > named exam1.com and exam2.com, which have two separated =20 > "configuration" elements in the same overlay configuration file, =20 > this single enrollment server must be able to accept the GET request =20= > both https://exam1.com/p2psip/enroll and = https://exam2.com/p2psip/enroll=20 > " from some peers for different overlay. Is such concept right? If =20 > right, how does this enrollment sever be implemented? > > Any comment and answer will be appreciated. > Thanks a lot in advance. > > BR, > Jeffrey > > =A5=BB=ABH=A5=F3=A5i=AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1K=B8=EA=B0T=A1A= =ABD=AB=FC=A9w=A4=A7=A6=AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5=A8=CF=A5=CE=A9=CE=B4= =A6=C5S=A5=BB=ABH=A5=F3=A4=BA=20 > =AEe=A1A=A8=C3=BD=D0=BEP=B7=B4=A6=B9=ABH=A5=F3=A1C > This email may contain confidential information. Please do not use =20 > or disclose it in any way and delete it if you are not the intended =20= > recipient. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Fri Jul 10 16:09:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE843A67D9 for ; Fri, 10 Jul 2009 16:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE0z+rqf7VhZ for ; Fri, 10 Jul 2009 16:09:55 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id C22F63A683B for ; Fri, 10 Jul 2009 16:09:54 -0700 (PDT) Received: by fxm18 with SMTP id 18so1189816fxm.37 for ; Fri, 10 Jul 2009 16:10:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.136 with SMTP id a8mr1347325faq.101.1247267420616; Fri, 10 Jul 2009 16:10:20 -0700 (PDT) In-Reply-To: References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> Date: Fri, 10 Jul 2009 19:10:20 -0400 Message-ID: From: Bruce Lowekamp To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 23:09:56 -0000 ekr already mentioned that AppAttach is supposed to come into the next draf= t. What if we have a 16 bit field in Attach and AttachLite that specifies role/purpose of the connection? No normative purpose in the base draft, but for use with future extensions. Specify maybe five values for neighbor, routing table, peer optimization, client responsible peer attachment, and client optimization, and allow for future code points. That would allow future extensions that want to specify/control client behavior more carefully to do so, but not make the base any more complicated or restrict its behavior. Possibly rather than a simple 16 bit field, this should be more like a Forwarding Option so that if additional data is required, it can be included. Bruce On Fri, Jul 10, 2009 at 6:04 PM, Ted Hardie wrote: > At 1:23 PM -0700 7/10/09, Eric Rescorla wrote: >>At Thu, 9 Jul 2009 14:03:08 -0700, >>Narayanan, Vidya wrote: >>> >>> I'm not sure I understand what you are saying. =C2=A0Are you saying tha= t >>> an Attach request without a preceding Join is indicative of joining >>> as a client? >> >>No, I'm saying that "client" isn't a first class concept in RELOAD. >>The generic procedures defined in RELOAD make peers handle client >>nodes correctly automatically. So, all that's required is that >>nodes which wish not to be part of the routing fabric and >>storage fabric not send the messages that would make them >>so. > > So, my personal preference is for "client" to be closer to a first > class concept, so that this behavior is explicit. =C2=A0That might take > the form of a different message after attach. =C2=A0That's largely a > style, thing, though, and I agree that the behavior you describe > works. =C2=A0But see below. > > > > >> >> >>> If so, a client finds a bootstrap peer and sends an >>> Attach request to its own node id, in order to find the node that it >>> is supposed to attach to? >> >>Yes. >> >> >>> =C2=A0AFAICT, this doesn't seem to be described >>> in the draft. >> >>That's because there is no new normative behavior. Clients simply >>don't send Join or Update. >> >> >>> =C2=A0Even if it is, I don't understand how a node >>> differentiates a client from another neighbor, because treating the >>> client as a neighbor and sending updates to all other neighbors will >>> create an incorrect view of the DHT for the other nodes. If you are >>> saying that all of this is implicit in the fact that an Attach was >>> received without a Join, it seems setting up for issues. =C2=A0I think = it >>> is better off to explicitly join as a client to avoid any ambiguity. >> >>A node doesn't know that an adjacency is a client or not. What it >>knows is that it's a node that hasn't sent any Updates and therefore >>shouldn't be advertised to other nodes in the overlay. It could >>be a client or it could be a node which just hasn't sent any >>Updates or Joins yet (but will eventually). It doesn't matter. This is >>a feature of the design, not a bug. > > My concern here is that without an explicit step, some set of > implementations may treat long post-Attach periods without > joins or updates as indicative that the relationship to the > attached node is not healthy. =C2=A0That might take the form of timeouts > or something similar. > > You can retain the current theory and avoid that ambiguity by > making the theory you've articulated in this email explicit in the > text. =C2=A0That would require some additional verbiage, but it should > not require anyone to actually change code. =C2=A0For the folks who > implement post-WG discussion, that kind of breadcrumb will be > pretty important. > > My two cents, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ted > > > > >> >>-Ekr >>_______________________________________________ >>P2PSIP mailing list >>P2PSIP@ietf.org >>https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From hardie@qualcomm.com Fri Jul 10 16:25:13 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7113F28C3A0 for ; Fri, 10 Jul 2009 16:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.872 X-Spam-Level: X-Spam-Status: No, score=-103.872 tagged_above=-999 required=5 tests=[AWL=-1.273, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grMIkWqKsAvJ for ; Fri, 10 Jul 2009 16:25:08 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 674243A6817 for ; Fri, 10 Jul 2009 16:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1247268332; x=1278804332; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20=0D=0A=20=20<20090708174319.E696A1C7B5B@kilo.net workresonance.com>=09=0D=0A=20=09=0D=0A=20 <20090710202307.388F01CAFC7@kilo.networkresonance.com>=09 =0D=0A=20=0D=0A=20|Date:=20Fri,=2010=20Jul=202009=2016:25:28=20-0700|To: =20Bruce=20Lowekamp=20|From:=20Ted=20Ha rdie=20|Subject:=20Re:=20[P2PSIP]=20 Client=20operation=20in=20RELOAD|CC:=20Eric=20Rescorla=20 ,=0D=0A=20=20=20=20=20=20=20=20 "Narayanan,=20Vidya"=0D=0A=09,=0D=0A =20=20=20=20=20=20=20=20"p2psip@ietf.org"=20|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5672"=3B=20 a=3D"20576898"; bh=LD8IPU/3Ph8HqUg9Vs8lbD7YcqL+PqyHA7+Hb2KHr8Y=; b=UpVxozgGnVelL+9Jobr7SYaUgczh/LWRLXFdcJ1Po7+Vd8tcA6E+AbmY XbhZvG7S1hmnuKsaphrooSf846fJLpNeQu8qJK39mIp8HVN9ZPSBDdk+h GSZ4aLb5VRsMKmqxG2P/m8azd63B9YKcrWsOnmMf/0Xb/C816+pheqPXR E=; X-IronPort-AV: E=McAfee;i="5300,2777,5672"; a="20576898" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2009 16:25:32 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6ANPVQq016562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Jul 2009 16:25:31 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6ANPV18027827 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Jul 2009 16:25:31 -0700 (PDT) Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 10 Jul 2009 16:25:30 -0700 Received: from [10.227.68.80] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 10 Jul 2009 16:25:30 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> Date: Fri, 10 Jul 2009 16:25:28 -0700 To: Bruce Lowekamp From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 23:25:13 -0000 At 4:10 PM -0700 7/10/09, Bruce Lowekamp wrote: >ekr already mentioned that AppAttach is supposed to come into the next draft. > >What if we have a 16 bit field in Attach and AttachLite that specifies >role/purpose of the connection? No normative purpose in the base >draft, but for use with future extensions. Specify maybe five values >for neighbor, routing table, peer optimization, client responsible >peer attachment, and client optimization, and allow for future code >points. In general, this sounds like a useful way forward. >That would allow future extensions that want to specify/control client >behavior more carefully to do so, but not make the base any more >complicated or restrict its behavior. > >Possibly rather than a simple 16 bit field, this should be more like a >Forwarding Option so that if additional data is required, it can be >included. > >Bruce > I don't have a strong opinion on whether to go with a fix-length field or a Forwarding Option, and I think the general idea could work either way. regards, Ted >On Fri, Jul 10, 2009 at 6:04 PM, Ted Hardie wrote: >> At 1:23 PM -0700 7/10/09, Eric Rescorla wrote: >>>At Thu, 9 Jul 2009 14:03:08 -0700, >>>Narayanan, Vidya wrote: >>>> >>>> I'm not sure I understand what you are saying. Are you saying that >>>> an Attach request without a preceding Join is indicative of joining >>>> as a client? >>> >>>No, I'm saying that "client" isn't a first class concept in RELOAD. >>>The generic procedures defined in RELOAD make peers handle client >>>nodes correctly automatically. So, all that's required is that >>>nodes which wish not to be part of the routing fabric and >>>storage fabric not send the messages that would make them >>>so. >> >> So, my personal preference is for "client" to be closer to a first >> class concept, so that this behavior is explicit. That might take >> the form of a different message after attach. That's largely a >> style, thing, though, and I agree that the behavior you describe >> works. But see below. >> >> >> >> >>> >>> >>>> If so, a client finds a bootstrap peer and sends an >>>> Attach request to its own node id, in order to find the node that it >>>> is supposed to attach to? >>> >>>Yes. >>> >>> >>>> AFAICT, this doesn't seem to be described >>>> in the draft. >>> >>>That's because there is no new normative behavior. Clients simply >>>don't send Join or Update. >>> >>> >>>> Even if it is, I don't understand how a node >>>> differentiates a client from another neighbor, because treating the >>>> client as a neighbor and sending updates to all other neighbors will >>>> create an incorrect view of the DHT for the other nodes. If you are >>>> saying that all of this is implicit in the fact that an Attach was >>>> received without a Join, it seems setting up for issues. I think it >>>> is better off to explicitly join as a client to avoid any ambiguity. >>> >>>A node doesn't know that an adjacency is a client or not. What it >>>knows is that it's a node that hasn't sent any Updates and therefore >>>shouldn't be advertised to other nodes in the overlay. It could >>>be a client or it could be a node which just hasn't sent any >>>Updates or Joins yet (but will eventually). It doesn't matter. This is >>>a feature of the design, not a bug. >> >> My concern here is that without an explicit step, some set of >> implementations may treat long post-Attach periods without >> joins or updates as indicative that the relationship to the >> attached node is not healthy. That might take the form of timeouts >> or something similar. >> >> You can retain the current theory and avoid that ambiguity by >> making the theory you've articulated in this email explicit in the >> text. That would require some additional verbiage, but it should >> not require anyone to actually change code. For the folks who >> implement post-WG discussion, that kind of breadcrumb will be > > pretty important. >> >> My two cents, >> Ted >> >> >> >> >>> >>>-Ekr >>>_______________________________________________ >>>P2PSIP mailing list >>>P2PSIP@ietf.org >>>https://www.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> From julian@orchidseed.org Fri Jul 10 19:51:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6169F3A68E5 for ; Fri, 10 Jul 2009 19:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5emzqCsmbEt for ; Fri, 10 Jul 2009 19:51:31 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 64E0D3A6841 for ; Fri, 10 Jul 2009 19:51:31 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so394410wff.31 for ; Fri, 10 Jul 2009 19:51:58 -0700 (PDT) Received: by 10.142.103.2 with SMTP id a2mr763043wfc.77.1247280718039; Fri, 10 Jul 2009 19:51:58 -0700 (PDT) Received: from ?10.0.1.2? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 30sm3515308wfa.35.2009.07.10.19.51.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 19:51:57 -0700 (PDT) Message-Id: <791EA8FC-65B1-493B-A698-68A859A0839A@orchidseed.org> From: Julian Cain To: p2psip@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 19:51:53 -0700 References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 02:51:32 -0000 Why would a node send the "purpose of the connection" in it's Attach? Attach is low level and hardly indicative of anything Overlay related. The Attach clearly states the purpose of the connection outright, what we do not is the reason for the Join and what role the joining node wishes to assume. jc On Jul 10, 2009, at 4:10 PM, Bruce Lowekamp wrote: > ekr already mentioned that AppAttach is supposed to come into the > next draft. > > What if we have a 16 bit field in Attach and AttachLite that specifies > role/purpose of the connection? No normative purpose in the base > draft, but for use with future extensions. Specify maybe five values > for neighbor, routing table, peer optimization, client responsible > peer attachment, and client optimization, and allow for future code > points. > > That would allow future extensions that want to specify/control client > behavior more carefully to do so, but not make the base any more > complicated or restrict its behavior. > > Possibly rather than a simple 16 bit field, this should be more like a > Forwarding Option so that if additional data is required, it can be > included. > > Bruce > > > On Fri, Jul 10, 2009 at 6:04 PM, Ted Hardie > wrote: >> At 1:23 PM -0700 7/10/09, Eric Rescorla wrote: >>> At Thu, 9 Jul 2009 14:03:08 -0700, >>> Narayanan, Vidya wrote: >>>> >>>> I'm not sure I understand what you are saying. Are you saying that >>>> an Attach request without a preceding Join is indicative of joining >>>> as a client? >>> >>> No, I'm saying that "client" isn't a first class concept in RELOAD. >>> The generic procedures defined in RELOAD make peers handle client >>> nodes correctly automatically. So, all that's required is that >>> nodes which wish not to be part of the routing fabric and >>> storage fabric not send the messages that would make them >>> so. >> >> So, my personal preference is for "client" to be closer to a first >> class concept, so that this behavior is explicit. That might take >> the form of a different message after attach. That's largely a >> style, thing, though, and I agree that the behavior you describe >> works. But see below. >> >> >> >> >>> >>> >>>> If so, a client finds a bootstrap peer and sends an >>>> Attach request to its own node id, in order to find the node that >>>> it >>>> is supposed to attach to? >>> >>> Yes. >>> >>> >>>> AFAICT, this doesn't seem to be described >>>> in the draft. >>> >>> That's because there is no new normative behavior. Clients simply >>> don't send Join or Update. >>> >>> >>>> Even if it is, I don't understand how a node >>>> differentiates a client from another neighbor, because treating the >>>> client as a neighbor and sending updates to all other neighbors >>>> will >>>> create an incorrect view of the DHT for the other nodes. If you are >>>> saying that all of this is implicit in the fact that an Attach was >>>> received without a Join, it seems setting up for issues. I think >>>> it >>>> is better off to explicitly join as a client to avoid any >>>> ambiguity. >>> >>> A node doesn't know that an adjacency is a client or not. What it >>> knows is that it's a node that hasn't sent any Updates and therefore >>> shouldn't be advertised to other nodes in the overlay. It could >>> be a client or it could be a node which just hasn't sent any >>> Updates or Joins yet (but will eventually). It doesn't matter. >>> This is >>> a feature of the design, not a bug. >> >> My concern here is that without an explicit step, some set of >> implementations may treat long post-Attach periods without >> joins or updates as indicative that the relationship to the >> attached node is not healthy. That might take the form of timeouts >> or something similar. >> >> You can retain the current theory and avoid that ambiguity by >> making the theory you've articulated in this email explicit in the >> text. That would require some additional verbiage, but it should >> not require anyone to actually change code. For the folks who >> implement post-WG discussion, that kind of breadcrumb will be >> pretty important. >> >> My two cents, >> Ted >> >> >> >> >>> >>> -Ekr >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From ekr@networkresonance.com Fri Jul 10 20:00:05 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E513A69AD for ; Fri, 10 Jul 2009 20:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm1T0YWtwxO7 for ; Fri, 10 Jul 2009 20:00:04 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id BF7C53A6841 for ; Fri, 10 Jul 2009 20:00:04 -0700 (PDT) Received: from dhcp-128-107-47-96.cisco.com (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C4B991CB330; Fri, 10 Jul 2009 20:01:42 -0700 (PDT) Date: Fri, 10 Jul 2009 20:01:42 -0700 From: Eric Rescorla To: Julian Cain In-Reply-To: <791EA8FC-65B1-493B-A698-68A859A0839A@orchidseed.org> References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> <791EA8FC-65B1-493B-A698-68A859A0839A@orchidseed.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090711030142.C4B991CB330@kilo.networkresonance.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 03:00:05 -0000 At Fri, 10 Jul 2009 19:51:53 -0700, Julian Cain wrote: > > > Why would a node send the "purpose of the connection" in it's Attach? > Attach is low level and hardly indicative of anything Overlay related. > The Attach clearly states the purpose of the connection outright, what > we do not is the reason for the Join and what role the joining node > wishes to assume. What do you mean? Only nodes which are going to store data send joins. That's what Join means. -Ekr From julian@orchidseed.org Fri Jul 10 21:00:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B719F3A6A48 for ; Fri, 10 Jul 2009 21:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EUDI7Thb+-a for ; Fri, 10 Jul 2009 21:00:52 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 1522D3A67D0 for ; Fri, 10 Jul 2009 21:00:51 -0700 (PDT) Received: by pzk36 with SMTP id 36so1268116pzk.29 for ; Fri, 10 Jul 2009 21:01:19 -0700 (PDT) Received: by 10.114.25.17 with SMTP id 17mr4366305way.70.1247284878977; Fri, 10 Jul 2009 21:01:18 -0700 (PDT) Received: from ?10.0.1.2? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id v39sm3180049wah.27.2009.07.10.21.01.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 21:01:18 -0700 (PDT) Message-Id: From: Julian Cain To: Eric Rescorla In-Reply-To: <20090711030142.C4B991CB330@kilo.networkresonance.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 21:01:14 -0700 References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> <791EA8FC-65B1-493B-A698-68A859A0839A@orchidseed.org> <20090711030142.C4B991CB330@kilo.networkresonance.com> X-Mailer: Apple Mail (2.935.3) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 04:00:52 -0000 On Jul 10, 2009, at 8:01 PM, Eric Rescorla wrote: > At Fri, 10 Jul 2009 19:51:53 -0700, > Julian Cain wrote: >> >> >> Why would a node send the "purpose of the connection" in it's Attach? >> Attach is low level and hardly indicative of anything Overlay >> related. >> The Attach clearly states the purpose of the connection outright, >> what >> we do not is the reason for the Join and what role the joining node >> wishes to assume. > > What do you mean? Only nodes which are going to store data send > joins. That's what Join means. Technically Join doesn't mean or indicate nodes that "are going to store data", instead Join indicates a node that WANT's to store and route. If the join_req fails the Client is still a Client otherwise it sends a series of Store's along with Update's and only then is the node considered a Peer inside of the ring vs a Client outside of the ring. I assume this AppAttach performs an Attach and then the AppAttach instead of a Join? > > -Ekr From ekr@networkresonance.com Fri Jul 10 21:25:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778893A6943 for ; Fri, 10 Jul 2009 21:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.208 X-Spam-Level: X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4a0Y1L2ATil for ; Fri, 10 Jul 2009 21:25:07 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id B789C3A6921 for ; Fri, 10 Jul 2009 21:25:05 -0700 (PDT) Received: from dhcp-128-107-47-96.cisco.com (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 90FB11CB381; Fri, 10 Jul 2009 21:26:44 -0700 (PDT) Date: Fri, 10 Jul 2009 21:26:44 -0700 From: Eric Rescorla To: Julian Cain In-Reply-To: References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> <791EA8FC-65B1-493B-A698-68A859A0839A@orchidseed.org> <20090711030142.C4B991CB330@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090711042644.90FB11CB381@kilo.networkresonance.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 04:25:08 -0000 At Fri, 10 Jul 2009 21:01:14 -0700, Julian Cain wrote: > > > On Jul 10, 2009, at 8:01 PM, Eric Rescorla wrote: > > > At Fri, 10 Jul 2009 19:51:53 -0700, > > Julian Cain wrote: > >> > >> > >> Why would a node send the "purpose of the connection" in it's Attach? > >> Attach is low level and hardly indicative of anything Overlay > >> related. > >> The Attach clearly states the purpose of the connection outright, > >> what > >> we do not is the reason for the Join and what role the joining node > >> wishes to assume. > > > > What do you mean? Only nodes which are going to store data send > > joins. That's what Join means. > > Technically Join doesn't mean or indicate nodes that "are going to > store data", instead Join indicates a node that WANT's to store and > route. Sure, but "store", not "route". If you don't send updates, you won't be routing. > If the join_req fails the Client is still a Client otherwise it > sends a series of Store's along with Update's and only then is the > node considered a Peer inside of the ring vs a Client outside of the > ring. Actually, the node (formerly Client) does not send Stores. Rather, the peer that it's taking over space from sends Stores. The node can of course send its own Stores to store data at any time. > I assume this AppAttach performs an Attach and then the AppAttach > instead of a Join? AppAttach (when it exists) doesn't have anything to do with clients. It's what you use to initiate connections for traffic other than RELOAD. RELOAD technically supports this already with hte application field, but our experience with implementatons was that people found using the same method for both purposes was really confusing. -Ekr From julian@orchidseed.org Fri Jul 10 23:12:00 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8DA3A6A8B for ; Fri, 10 Jul 2009 23:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKJSESQLOZ+E for ; Fri, 10 Jul 2009 23:11:59 -0700 (PDT) Received: from mail-px0-f201.google.com (mail-px0-f201.google.com [209.85.216.201]) by core3.amsl.com (Postfix) with ESMTP id 8ED423A692B for ; Fri, 10 Jul 2009 23:11:59 -0700 (PDT) Received: by pxi39 with SMTP id 39so1390805pxi.29 for ; Fri, 10 Jul 2009 23:12:26 -0700 (PDT) Received: by 10.114.160.2 with SMTP id i2mr4534917wae.101.1247292746495; Fri, 10 Jul 2009 23:12:26 -0700 (PDT) Received: from ?10.0.1.2? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id j26sm3348525waf.28.2009.07.10.23.12.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 23:12:25 -0700 (PDT) Message-Id: <14BBFF5C-E82B-443A-8ADB-17F6AD258AFF@orchidseed.org> From: jc To: Eric Rescorla In-Reply-To: <20090711042644.90FB11CB381@kilo.networkresonance.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-550086857 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 23:12:22 -0700 References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> <791EA8FC-65B1-493B-A698-68A859A0839A@orchidseed.org> <20090711030142.C4B991CB330@kilo.networkresonance.com> <20090711042644.90FB11CB381@kilo.networkresonance.com> X-Mailer: Apple Mail (2.935.3) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 06:12:00 -0000 --Apple-Mail-1-550086857 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 10, 2009, at 9:26 PM, Eric Rescorla wrote: >> >> Technically Join doesn't mean or indicate nodes that "are going to >> store data", instead Join indicates a node that WANT's to store and >> route. > > Sure, but "store", not "route". If you don't send updates, you > won't be routing. > That's incorrect, Update is required to Join thus you MUST always perform them given the default Chord algorithm. The only time you needn't send Updates is Client vs Peer operation mode which is vaguely outlined in the current draft. jc --Apple-Mail-1-550086857 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jul 10, 2009, = at 9:26 PM, Eric Rescorla wrote:


Technically Join doesn't mean or indicate nodes that "are = going to  
store data", = instead Join indicates a node that WANT's to store and =  
route.

Sure, but "store", not "route". = If you don't send updates, you
won't be = routing.


That's incorrect, Update is required to = Join thus you MUST always perform them given the default Chord = algorithm. The only time you needn't send Updates is Client vs Peer = operation mode which is vaguely outlined in the current = draft.

jc
= --Apple-Mail-1-550086857-- From lilichun@gmail.com Sat Jul 11 21:00:33 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCD93A6C1C for ; Sat, 11 Jul 2009 21:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dX4LIreBDgh for ; Sat, 11 Jul 2009 21:00:33 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id DCE253A6B0F for ; Sat, 11 Jul 2009 21:00:32 -0700 (PDT) Received: by yxe34 with SMTP id 34so787340yxe.29 for ; Sat, 11 Jul 2009 21:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V1sPma2lQSabjgEGAkXopUZsaESWK0tsAd/BE80fyjk=; b=SA9uNTSlBtYrt7guvALvzmrSuXuqGAp5F3mPUyDKufe/vJEWDqH9zz0WjlfuYDh5G1 1WOQ3iRS0EGhEOzq33zkSJCZNQTF1pylweYtZ3SDNwelP6sxWAyZbNhEbQIsknbGWDXq IHiSFu0osr8mKSmwMsISIMEnKLhkH495eCbNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GFxz4/yJ26gZa+BhzcDTcKTZ2rmra3aexBuv6FZKS8YGOdtMitt3PTLlnfzGEpCy9+ wPoduI47hAnFoVfS9+7u97Fxc/JxX/6L64TCQ41YggA+rAFEONIZgamHPmHIr/+m+tmj js7XTij/6BZXZNGN1GWR2WpQfOaabQukcCXPk= MIME-Version: 1.0 Received: by 10.150.189.20 with SMTP id m20mr5643281ybf.219.1247371259630; Sat, 11 Jul 2009 21:00:59 -0700 (PDT) In-Reply-To: References: Date: Sun, 12 Jul 2009 12:00:59 +0800 Message-ID: <7d6b50690907112100j61fb7088y82c41ce67dd25f4c@mail.gmail.com> From: lichun li To: shen.jiong@zte.com.cn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] New draft on content sharing usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 04:00:34 -0000 Interesting. I think we may start considering using RELOAD for applications other than P2PSIP. Some questions and comments are below. It seems that all the contents are provided by service provider. Can users upload and share contents? Servers or user PCs form the the RELOAD overlay for content sharing? I think the RELOAD overlay is more than a CDN. CDN is not responsible for data durability but traffic localization. DHT overlay can assure data durability, and this draft adds CDN function to RELOAD. Other than store files, the RELOAD overlay may store user list for up-layer distributed tracker function. So I think the RELOAD overlay may have three functions: CDN, file storing and user list storing. The RELOAD overlay may provide all three functions to some contents (e.g. content provided by service provider) and only part functions to other contents (e.g. contents provided by users)= . On Wed, Jul 1, 2009 at 9:16 AM, wrote: > > Hi all, > > We have submitted a draft on content sharing usage for RELOAD. It provide= s > the functionality of distributing and fetching shared content efficiently= to > and from a P2P overlay network, which performs as Content Delivery Networ= k > and is service insensitive. > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-shen-p2psip-content-sharing-00.= txt. > =A0Comments are welcome. > > > Thanks, > Jiong > > > -------------------------------------------------------- > ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0= in=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organizat= ion.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0name= d=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=A0p= ermitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=A0to= =A0others. > This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confid= ential=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual= =A0or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0re= ceived=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0o= f=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0= those=A0of=A0the=A0individual=A0sender. > This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by= =A0ZTE=A0Anti-Spam=A0system. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT From vidyan@qualcomm.com Sat Jul 11 23:09:43 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BA03A6994 for ; Sat, 11 Jul 2009 23:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.456 X-Spam-Level: X-Spam-Status: No, score=-105.456 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZI0oA9i-IjB for ; Sat, 11 Jul 2009 23:09:42 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 05DFA3A6452 for ; Sat, 11 Jul 2009 23:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1247379012; x=1278915012; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Hardie,=20Ted"=20,=20Bruce=20Low ekamp=20|CC:=20Eric=20Rescorla=20,=0D=0A=20=20=20=20=20=20=20=20"p2psi p@ietf.org"=0D=0A=09|Date:=20Sat,=2011 =20Jul=202009=2023:10:07=20-0700|Subject:=20RE:=20[P2PSIP ]=20Client=20operation=20in=20RELOAD|Thread-Topic:=20[P2P SIP]=20Client=20operation=20in=20RELOAD|Thread-Index:=20A coBtbewoeHEI+kQRqm5G4AKA67ToABAZfiw|Message-ID:=20|References:=20=0D=0A=20=20<200907 08174319.E696A1C7B5B@kilo.networkresonance.com>=0D=0A=09 =20=0D=0A=09=20<20090710202307.388F01CAFC7 @kilo.networkresonance.com>=0D=0A=09=20=0D=0A=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5673"=3B=20a=3D"20596128"; bh=8zejItqslr9s//ebe2q1c9PDQd0KVHaC0Zi/VKFDDUo=; b=HBlgcQKgorHufLQokG9u904Pqa4dTz+7Xh+qoYfP0g6vaNvDX8ULqezk /CmM3n1ZGNhJnuk72Kgku7uZVGNKbZIca1hnCbAph6hc9VvG2TEoACfqx trVmf0i2eKP2zYWzEM/THflg+JRF0k7QTlLFnwzyBbzhIV6CS1K8yD6zw 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5673"; a="20596128" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2009 23:10:11 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6C6ABxW005513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 11 Jul 2009 23:10:11 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6C6AAEg001137 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 11 Jul 2009 23:10:10 -0700 (PDT) Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Sat, 11 Jul 2009 23:10:10 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Sat, 11 Jul 2009 23:10:10 -0700 From: "Narayanan, Vidya" To: "Hardie, Ted" , Bruce Lowekamp Date: Sat, 11 Jul 2009 23:10:07 -0700 Thread-Topic: [P2PSIP] Client operation in RELOAD Thread-Index: AcoBtbewoeHEI+kQRqm5G4AKA67ToABAZfiw Message-ID: References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 06:09:43 -0000 I'd support this as well. I think this would be quite useful.=20 Vidya > -----Original Message----- > From: Hardie, Ted > Sent: Friday, July 10, 2009 4:25 PM > To: Bruce Lowekamp > Cc: Eric Rescorla; Narayanan, Vidya; p2psip@ietf.org > Subject: Re: [P2PSIP] Client operation in RELOAD >=20 > At 4:10 PM -0700 7/10/09, Bruce Lowekamp wrote: > >ekr already mentioned that AppAttach is supposed to come into the next > draft. > > > >What if we have a 16 bit field in Attach and AttachLite that specifies > >role/purpose of the connection? No normative purpose in the base > >draft, but for use with future extensions. Specify maybe five values > >for neighbor, routing table, peer optimization, client responsible > >peer attachment, and client optimization, and allow for future code > >points. >=20 > In general, this sounds like a useful way forward. >=20 >=20 > >That would allow future extensions that want to specify/control client > >behavior more carefully to do so, but not make the base any more > >complicated or restrict its behavior. > > > >Possibly rather than a simple 16 bit field, this should be more like a > >Forwarding Option so that if additional data is required, it can be > >included. > > > >Bruce > > >=20 > I don't have a strong opinion on whether to go with a fix-length > field or a Forwarding Option, and I think the general idea could > work either way. > regards, > Ted >=20 >=20 >=20 >=20 > >On Fri, Jul 10, 2009 at 6:04 PM, Ted Hardie > wrote: > >> At 1:23 PM -0700 7/10/09, Eric Rescorla wrote: > >>>At Thu, 9 Jul 2009 14:03:08 -0700, > >>>Narayanan, Vidya wrote: > >>>> > >>>> I'm not sure I understand what you are saying. Are you saying > that > >>>> an Attach request without a preceding Join is indicative of > joining > >>>> as a client? > >>> > >>>No, I'm saying that "client" isn't a first class concept in RELOAD. > >>>The generic procedures defined in RELOAD make peers handle client > >>>nodes correctly automatically. So, all that's required is that > >>>nodes which wish not to be part of the routing fabric and > >>>storage fabric not send the messages that would make them > >>>so. > >> > >> So, my personal preference is for "client" to be closer to a first > >> class concept, so that this behavior is explicit. That might take > >> the form of a different message after attach. That's largely a > >> style, thing, though, and I agree that the behavior you describe > >> works. But see below. > >> > >> > >> > >> > >>> > >>> > >>>> If so, a client finds a bootstrap peer and sends an > >>>> Attach request to its own node id, in order to find the node that > it > >>>> is supposed to attach to? > >>> > >>>Yes. > >>> > >>> > >>>> AFAICT, this doesn't seem to be described > >>>> in the draft. > >>> > >>>That's because there is no new normative behavior. Clients simply > >>>don't send Join or Update. > >>> > >>> > >>>> Even if it is, I don't understand how a node > >>>> differentiates a client from another neighbor, because treating > the > >>>> client as a neighbor and sending updates to all other neighbors > will > >>>> create an incorrect view of the DHT for the other nodes. If you > are > >>>> saying that all of this is implicit in the fact that an Attach was > >>>> received without a Join, it seems setting up for issues. I think > it > >>>> is better off to explicitly join as a client to avoid any > ambiguity. > >>> > >>>A node doesn't know that an adjacency is a client or not. What it > >>>knows is that it's a node that hasn't sent any Updates and therefore > >>>shouldn't be advertised to other nodes in the overlay. It could > >>>be a client or it could be a node which just hasn't sent any > >>>Updates or Joins yet (but will eventually). It doesn't matter. This > is > >>>a feature of the design, not a bug. > >> > >> My concern here is that without an explicit step, some set of > >> implementations may treat long post-Attach periods without > >> joins or updates as indicative that the relationship to the > >> attached node is not healthy. That might take the form of timeouts > >> or something similar. > >> > >> You can retain the current theory and avoid that ambiguity by > >> making the theory you've articulated in this email explicit in the > >> text. That would require some additional verbiage, but it should > >> not require anyone to actually change code. For the folks who > >> implement post-WG discussion, that kind of breadcrumb will be > > > pretty important. > >> > >> My two cents, > >> Ted > >> > >> > >> > >> > >>> > >>>-Ekr > >>>_______________________________________________ > >>>P2PSIP mailing list > >>>P2PSIP@ietf.org > >>>https://www.ietf.org/mailman/listinfo/p2psip > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > >> From ekr@networkresonance.com Sun Jul 12 11:31:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE8428C168 for ; Sun, 12 Jul 2009 11:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mv84NKhG56w for ; Sun, 12 Jul 2009 11:31:31 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id B7C0E28C163 for ; Sun, 12 Jul 2009 11:31:31 -0700 (PDT) Received: from dhcp-128-107-47-96.cisco.com (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 784EB1CBC2F; Sun, 12 Jul 2009 11:33:20 -0700 (PDT) Date: Sun, 12 Jul 2009 11:33:20 -0700 From: Eric Rescorla To: "Narayanan, Vidya" In-Reply-To: References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090712183320.784EB1CBC2F@kilo.networkresonance.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 18:31:32 -0000 At Sat, 11 Jul 2009 23:10:07 -0700, Narayanan, Vidya wrote: > > I'd support this as well. I think this would be quite useful. > > Vidya > > > -----Original Message----- > > From: Hardie, Ted > > Sent: Friday, July 10, 2009 4:25 PM > > To: Bruce Lowekamp > > Cc: Eric Rescorla; Narayanan, Vidya; p2psip@ietf.org > > Subject: Re: [P2PSIP] Client operation in RELOAD > > > > At 4:10 PM -0700 7/10/09, Bruce Lowekamp wrote: > > >ekr already mentioned that AppAttach is supposed to come into the next > > draft. > > > > > >What if we have a 16 bit field in Attach and AttachLite that specifies > > >role/purpose of the connection? No normative purpose in the base > > >draft, but for use with future extensions. Specify maybe five values > > >for neighbor, routing table, peer optimization, client responsible > > >peer attachment, and client optimization, and allow for future code > > >points. > > > > In general, this sounds like a useful way forward. I don't see that this change adds any value. It's just additional cruft. -Ekr From SRS0=FJcfNg=DF=vzw.blackberry.net=davidabryan@srs.bis.na.blackberry.com Sun Jul 12 12:50:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C56928C1AD; Sun, 12 Jul 2009 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe7KB+q-Tre6; Sun, 12 Jul 2009 12:50:54 -0700 (PDT) Received: from smtp09.bis.na.blackberry.com (smtp09.bis.na.blackberry.com [216.9.248.56]) by core3.amsl.com (Postfix) with ESMTP id 8ED9C28C1A6; Sun, 12 Jul 2009 12:50:54 -0700 (PDT) Received: from bxe1059.bisx.prod.on.blackberry (bxe1059.bisx.prod.on.blackberry [172.20.205.74]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id n6CJImjX029579; Sun, 12 Jul 2009 19:52:10 GMT X-rim-org-msg-ref-id: 1778312273 Message-ID: <1778312273-1247428283-cardhu_decombobulator_blackberry.rim.net-349514969-@bxe1059.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com><20090710202307.388F01CAFC7@kilo.networkresonance.com><20090712183320.784EB1CBC2F@kilo.networkresonance.com> In-Reply-To: <20090712183320.784EB1CBC2F@kilo.networkresonance.com> Sensitivity: Normal Importance: Normal To: "Eric Rescorla" , p2psip-bounces@ietf.org, "Narayanan, Vidya" From: "David A. Bryan" Date: Sun, 12 Jul 2009 19:51:52 +0000 Content-Type: text/plain MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dbryan@ethernot.org List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 19:52:03 -0000 QXQgbGVhc3QgYXMgdGhlIGRpc2N1c3Npb24gaGFzIGdvbmUgc28gZmFyLCBJIGFjdHVhbGx5IGxp a2UgdGhlIGlkZWEgb2YgdGhpcyBteXNlbGYsIHBhcnRpY3VsYXJseSB1c2luZyBhbiBvcHRpb24g c3RydWN0dXJlIG9mIHNvbWUgc29ydC4NCg0KVGhlcmUgaXMgYWxyZWFkeSBhIGJpdCBvZiBjcnVm dCBoZXJlIGFuZCB0aGVyZSBpbiB0aGUgcHJvdG9jb2wgKG15IHBlcnNvbmFsIHRha2UgaXMgdGhh dCBpdCBpcyBhIGJpdCB0b28gaGVhdnkgaW4gY3VycmVudCBmb3JtKSwgYnV0IHRoaXMgYWN0dWFs bHkgbG9va3MgdXNlZnVsIHRvIG1lLCBzbyBmb3Igbm93LCBJJ20gYmVoaW5kIHRoZSBpZGVhIG9m IGFkZGluZyBpdC4NCg0KRGF2aWQgKGFzIGluZGl2aWR1YWwpDQpTZW50IGZyb20gbXkgbW9iaWxl IGRldmljZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmljIFJlc2Nv cmxhIDxla3JAbmV0d29ya3Jlc29uYW5jZS5jb20+DQoNCkRhdGU6IFN1biwgMTIgSnVsIDIwMDkg MTE6MzM6MjAgDQpUbzogTmFyYXlhbmFuLCBWaWR5YTx2aWR5YW5AcXVhbGNvbW0uY29tPg0KQ2M6 IHAycHNpcEBpZXRmLm9yZzxwMnBzaXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1AyUFNJUF0g Q2xpZW50IG9wZXJhdGlvbiBpbiBSRUxPQUQNCg0KDQpBdCBTYXQsIDExIEp1bCAyMDA5IDIzOjEw OjA3IC0wNzAwLA0KTmFyYXlhbmFuLCBWaWR5YSB3cm90ZToNCj4NCj4gSSdkIHN1cHBvcnQgdGhp cyBhcyB3ZWxsLiBJIHRoaW5rIHRoaXMgd291bGQgYmUgcXVpdGUgdXNlZnVsLg0KPg0KPiBWaWR5 YQ0KPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSGFyZGllLCBU ZWQNCj4gPiBTZW50OiBGcmlkYXksIEp1bHkgMTAsIDIwMDkgNDoyNSBQTQ0KPiA+IFRvOiBCcnVj ZSBMb3dla2FtcA0KPiA+IENjOiBFcmljIFJlc2NvcmxhOyBOYXJheWFuYW4sIFZpZHlhOyBwMnBz aXBAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW1AyUFNJUF0gQ2xpZW50IG9wZXJhdGlvbiBp biBSRUxPQUQNCj4gPg0KPiA+IEF0IDQ6MTAgUE0gLTA3MDAgNy8xMC8wOSwgQnJ1Y2UgTG93ZWth bXAgd3JvdGU6DQo+ID4gPmVrciBhbHJlYWR5IG1lbnRpb25lZCB0aGF0IEFwcEF0dGFjaCBpcyBz dXBwb3NlZCB0byBjb21lIGludG8gdGhlIG5leHQNCj4gPiBkcmFmdC4NCj4gPiA+DQo+ID4gPldo YXQgaWYgd2UgaGF2ZSBhIDE2IGJpdCBmaWVsZCBpbiBBdHRhY2ggYW5kIEF0dGFjaExpdGUgdGhh dCBzcGVjaWZpZXMNCj4gPiA+cm9sZS9wdXJwb3NlIG9mIHRoZSBjb25uZWN0aW9uPyAgTm8gbm9y bWF0aXZlIHB1cnBvc2UgaW4gdGhlIGJhc2UNCj4gPiA+ZHJhZnQsIGJ1dCBmb3IgdXNlIHdpdGgg ZnV0dXJlIGV4dGVuc2lvbnMuICBTcGVjaWZ5IG1heWJlIGZpdmUgdmFsdWVzDQo+ID4gPmZvciBu ZWlnaGJvciwgcm91dGluZyB0YWJsZSwgcGVlciBvcHRpbWl6YXRpb24sIGNsaWVudCByZXNwb25z aWJsZQ0KPiA+ID5wZWVyIGF0dGFjaG1lbnQsIGFuZCBjbGllbnQgb3B0aW1pemF0aW9uLCBhbmQg YWxsb3cgZm9yIGZ1dHVyZSBjb2RlDQo+ID4gPnBvaW50cy4NCj4gPg0KPiA+IEluIGdlbmVyYWws IHRoaXMgc291bmRzIGxpa2UgYSB1c2VmdWwgd2F5IGZvcndhcmQuDQoNCkkgZG9uJ3Qgc2VlIHRo YXQgdGhpcyBjaGFuZ2UgYWRkcyBhbnkgdmFsdWUuIEl0J3MganVzdCBhZGRpdGlvbmFsIGNydWZ0 Lg0KDQotRWtyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KUDJQU0lQIG1haWxpbmcgbGlzdA0KUDJQU0lQQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0K From ekr@networkresonance.com Sun Jul 12 13:36:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2D228C187; Sun, 12 Jul 2009 13:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.408 X-Spam-Level: *** X-Spam-Status: No, score=3.408 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_PACBELL_D=3.944, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fxH7T7c1PRq; Sun, 12 Jul 2009 13:36:47 -0700 (PDT) Received: from kilo.networkresonance.com (adsl-69-228-190-230.dsl.snfc21.pacbell.net [69.228.190.230]) by core3.amsl.com (Postfix) with ESMTP id 773DC28C1AD; Sun, 12 Jul 2009 13:36:47 -0700 (PDT) Received: from dhcp-128-107-47-96.cisco.com (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D1AC11CBC8A; Sun, 12 Jul 2009 13:38:37 -0700 (PDT) Date: Sun, 12 Jul 2009 13:38:37 -0700 From: Eric Rescorla To: dbryan@ethernot.org In-Reply-To: <1778312273-1247428283-cardhu_decombobulator_blackberry.rim.net-349514969-@bxe1059.bisx.prod.on.blackberry> References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> <20090712183320.784EB1CBC2F@kilo.networkresonance.com> <1778312273-1247428283-cardhu_decombobulator_blackberry.rim.net-349514969-@bxe1059.bisx.prod.on.blackberry> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090712203837.D1AC11CBC8A@kilo.networkresonance.com> Cc: "p2psip@ietf.org" , p2psip-bounces@ietf.org Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 20:36:52 -0000 At Sun, 12 Jul 2009 19:51:52 +0000, David A. Bryan wrote: > There is already a bit of cruft here and there in the protocol (my > personal take is that it is a bit too heavy in current form), but > this actually looks useful to me, so for now, I'm behind the idea of > adding it. Not to put too fine a point on it, but this is really a not very useful complaint. If you think the protocol has too much cruft, how about identifying some bloat and explaining how to remove it? -Ekr From SRS0=FJcfNg=DF=vzw.blackberry.net=davidabryan@srs.bis.na.blackberry.com Sun Jul 12 13:53:18 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF7A3A6C6D; Sun, 12 Jul 2009 13:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.789 X-Spam-Level: X-Spam-Status: No, score=-4.789 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZGfAk-KJP6w; Sun, 12 Jul 2009 13:53:17 -0700 (PDT) Received: from smtp06.bis.na.blackberry.com (smtp06.bis.na.blackberry.com [216.9.248.53]) by core3.amsl.com (Postfix) with ESMTP id 67F4C3A6A84; Sun, 12 Jul 2009 13:53:16 -0700 (PDT) Received: from bxe1059.bisx.prod.on.blackberry (bxe1059.bisx.prod.on.blackberry [172.20.205.74]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id n6CKeRgE004140; Sun, 12 Jul 2009 20:53:31 GMT X-rim-org-msg-ref-id: 1800369555 Message-ID: <1800369555-1247432025-cardhu_decombobulator_blackberry.rim.net-2088609465-@bxe1059.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com><20090710202307.388F01CAFC7@kilo.networkresonance.com><20090712183320.784EB1CBC2F@kilo.networkresonance.com><1778312273-1247428283-cardhu_decombobulator_blackberry.rim.net-349514969-@bxe1059.bisx.prod.on.blackberry><20090712203837.D1AC11CBC8A@kilo.networkresonance.com> In-Reply-To: <20090712203837.D1AC11CBC8A@kilo.networkresonance.com> Sensitivity: Normal Importance: Normal To: "Eric Rescorla" , dbryan@ethernot.org From: "David A. Bryan" Date: Sun, 12 Jul 2009 20:54:14 +0000 Content-Type: text/plain MIME-Version: 1.0 Cc: p2psip-bounces@ietf.org, "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dbryan@ethernot.org List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 20:53:18 -0000 QWN0dWFsbHkgdGhpcyBpcyBtb3JlIG9mIGEgZ2VuZXJhbCBjb21tZW50IHRoYXQgaXQgaXMgYmln IGVub3VnaCB0aGF0IHVzaW5nIGl0IGFzIGFuIGV4Y3VzZSB0byBub3QgaW5jbHVkZSBzb21ldGhp bmcgaXNuJ3QgcmVhbGx5IGEgdmFsaWQgcmVhc29uLiAoTW9zdCBvZiB0aGUgdGhpbmdzIEkgcGVy c29uYWxseSB2aWV3IGFzIGNydWZ0IChtYW5kYXRvcnkgVExTLCBmb3IgZXhhbXBsZSkgd2VyZSwg dW5mb3J0dW5hdGVseSwgV0cgZGVjaXNpb25zLCBzbyBubyBwb2ludCBpbiBteSBjb21wbGFpbmlu ZyBhZ2FpbikNCg0KTXkgcG9pbnQgaXMgbW9yZSB0aGF0IHlvdSBzYXlpbmcgInlvdSBkb24ndCBs aWtlIGNydWZ0IiBpcyBub3QgYSB2ZXJ5IHdlbGwgYXJ0aWN1bGF0ZWQgcmVhc29uIHRvIG5vdCBp bmNsdWRlIGEgMTYgYml0IGZpZWxkIGluIGFuIGFscmVhZHkgMTQxIHBhZ2UgZG9jdW1lbnQuIEkg dGhpbmsgd2UgaGF2ZSBpbmNsdWRlZCBlbm91Z2ggdGhhdCwgdGhpcyBsb29rcyB0byBtZSBhcyB1 c2VmdWwgYXMgbWFueSBvdGhlciB0aGluZ3MgaW4gdGhlIGRyYWZ0LCBhbmQgSSBwZXJzb25hbGx5 IHN1cHBvcnQgaXQuDQoNCkRhdmlkIChhcyBpbmRpdmlkdWFsKQ0KU2VudCBmcm9tIG15IG1vYmls ZSBkZXZpY2UNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRXJpYyBSZXNj b3JsYSA8ZWtyQG5ldHdvcmtyZXNvbmFuY2UuY29tPg0KDQpEYXRlOiBTdW4sIDEyIEp1bCAyMDA5 IDEzOjM4OjM3IA0KVG86IDxkYnJ5YW5AZXRoZXJub3Qub3JnPg0KQ2M6IEVyaWMgUmVzY29ybGE8 ZWtyQG5ldHdvcmtyZXNvbmFuY2UuY29tPjsgPHAycHNpcC1ib3VuY2VzQGlldGYub3JnPjsgTmFy YXlhbmFuLCBWaWR5YTx2aWR5YW5AcXVhbGNvbW0uY29tPjsgcDJwc2lwQGlldGYub3JnPHAycHNp cEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUDJQU0lQXSBDbGllbnQgb3BlcmF0aW9uIGluIFJF TE9BRA0KDQoNCkF0IFN1biwgMTIgSnVsIDIwMDkgMTk6NTE6NTIgKzAwMDAsDQpEYXZpZCBBLiBC cnlhbiB3cm90ZToNCj4gVGhlcmUgaXMgYWxyZWFkeSBhIGJpdCBvZiBjcnVmdCBoZXJlIGFuZCB0 aGVyZSBpbiB0aGUgcHJvdG9jb2wgKG15DQo+IHBlcnNvbmFsIHRha2UgaXMgdGhhdCBpdCBpcyBh IGJpdCB0b28gaGVhdnkgaW4gY3VycmVudCBmb3JtKSwgYnV0DQo+IHRoaXMgYWN0dWFsbHkgbG9v a3MgdXNlZnVsIHRvIG1lLCBzbyBmb3Igbm93LCBJJ20gYmVoaW5kIHRoZSBpZGVhIG9mDQo+IGFk ZGluZyBpdC4NCg0KTm90IHRvIHB1dCB0b28gZmluZSBhIHBvaW50IG9uIGl0LCBidXQgdGhpcyBp cyByZWFsbHkgYSBub3QgdmVyeQ0KdXNlZnVsIGNvbXBsYWludC4gSWYgeW91IHRoaW5rIHRoZSBw cm90b2NvbCBoYXMgdG9vIG11Y2ggY3J1ZnQsDQpob3cgYWJvdXQgaWRlbnRpZnlpbmcgc29tZSBi bG9hdCBhbmQgZXhwbGFpbmluZyBob3cgdG8gcmVtb3ZlDQppdD8NCg0KLUVrcg0K From ekr@networkresonance.com Sun Jul 12 14:06:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B2228C1AD; Sun, 12 Jul 2009 14:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.408 X-Spam-Level: *** X-Spam-Status: No, score=3.408 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_PACBELL_D=3.944, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJEdoP-hQf0O; Sun, 12 Jul 2009 14:06:18 -0700 (PDT) Received: from kilo.networkresonance.com (adsl-69-228-190-230.dsl.snfc21.pacbell.net [69.228.190.230]) by core3.amsl.com (Postfix) with ESMTP id 9F92528C187; Sun, 12 Jul 2009 14:06:18 -0700 (PDT) Received: from dhcp-128-107-47-96.cisco.com (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 65B461CBC98; Sun, 12 Jul 2009 14:08:09 -0700 (PDT) Date: Sun, 12 Jul 2009 14:08:09 -0700 From: Eric Rescorla To: dbryan@ethernot.org In-Reply-To: <1800369555-1247432025-cardhu_decombobulator_blackberry.rim.net-2088609465-@bxe1059.bisx.prod.on.blackberry> References: <20090708174319.E696A1C7B5B@kilo.networkresonance.com> <20090710202307.388F01CAFC7@kilo.networkresonance.com> <20090712183320.784EB1CBC2F@kilo.networkresonance.com> <1778312273-1247428283-cardhu_decombobulator_blackberry.rim.net-349514969-@bxe1059.bisx.prod.on.blackberry> <20090712203837.D1AC11CBC8A@kilo.networkresonance.com> <1800369555-1247432025-cardhu_decombobulator_blackberry.rim.net-2088609465-@bxe1059.bisx.prod.on.blackberry> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090712210809.65B461CBC98@kilo.networkresonance.com> Cc: "p2psip@ietf.org" , p2psip-bounces@ietf.org Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 21:06:19 -0000 At Sun, 12 Jul 2009 20:54:14 +0000, David A. Bryan wrote: > > Actually this is more of a general comment that it is big enough > that using it as an excuse to not include something isn't really a > valid reason. So you'll totally support it when I suggest we incorporate a feature to carry around BGP route tables? After all, we might need that someday and if the protocol is bloated already, no harm no foul, right? > My point is more that you saying "you don't like cruft" is not a > very well articulated reason to not include a 16 bit field in an > already 141 page document. I think we have included enough that, > this looks to me as useful as many other things in the draft, and I > personally support it. Of course, you're just totally mischaracterizing what I said, which was: I don't see that this change adds any value. It's just additional cruft. To be clear, my objection isn't just that I don't like cruft, but rather that this feature is useless. Actually, now that I look at it, it's worse than useless, it's actively harmful; RELOAD doesn't include clients as a first-class concept for a good reason, it's not necessary and it interferes with the orthogonality of the protocol, which is almost never a good architectural decision. It's particularly bad in this case because we're adding an ad hoc indicator that receivers don't process but that categorizes nodes in an ill-defined way. In fact, of the five possible settings Bruce listed, I don't know what two of them ("peer optimization" and "client optimization") mean, and one distinction (neighbor versus routing table) only makes sense with specific overlays, and so properly belongs at the Topology Plugin Layer. -Ekr From bbl@lowekamp.net Sun Jul 12 14:15:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C1428C1D7; Sun, 12 Jul 2009 14:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZogWlNo9lb0; Sun, 12 Jul 2009 14:15:21 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 53C6728C1DA; Sun, 12 Jul 2009 14:15:21 -0700 (PDT) Received: by fxm18 with SMTP id 18so1863078fxm.37 for ; Sun, 12 Jul 2009 14:15:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.136 with SMTP id a8mr1647587faq.101.1247433348854; Sun, 12 Jul 2009 14:15:48 -0700 (PDT) In-Reply-To: <20090712210809.65B461CBC98@kilo.networkresonance.com> References: <20090712183320.784EB1CBC2F@kilo.networkresonance.com> <1778312273-1247428283-cardhu_decombobulator_blackberry.rim.net-349514969-@bxe1059.bisx.prod.on.blackberry> <20090712203837.D1AC11CBC8A@kilo.networkresonance.com> <1800369555-1247432025-cardhu_decombobulator_blackberry.rim.net-2088609465-@bxe1059.bisx.prod.on.blackberry> <20090712210809.65B461CBC98@kilo.networkresonance.com> Date: Sun, 12 Jul 2009 17:15:48 -0400 Message-ID: From: Bruce Lowekamp To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" , p2psip-bounces@ietf.org Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 21:15:22 -0000 On Sun, Jul 12, 2009 at 5:08 PM, Eric Rescorla wr= ote: > At Sun, 12 Jul 2009 20:54:14 +0000, > David A. Bryan wrote: >> >> Actually this is more of a general comment that it is big enough >> that using it as an excuse to not include something isn't really a >> valid reason. > > So you'll totally support it when I suggest we incorporate a feature > to carry around BGP route tables? After all, we might need that > someday and if the protocol is bloated already, no harm no > foul, right? > > >> My point is more that you saying "you don't like cruft" is not a >> very well articulated reason to not include a 16 bit field in an >> already 141 page document. I think we have included enough that, >> this looks to me as useful as many other things in the draft, and I >> personally support it. > > Of course, you're just totally mischaracterizing what I said, which > was: > > =C2=A0 I don't see that this change adds any value. It's just additional > =C2=A0 cruft. > > To be clear, my objection isn't just that I don't like cruft, but > rather that this feature is useless. Actually, now that I look at it, > it's worse than useless, it's actively harmful; RELOAD doesn't include > clients as a first-class concept for a good reason, it's not necessary > and it interferes with the orthogonality of the protocol, which is > almost never a good architectural decision. > > It's particularly bad in this case because we're adding an ad hoc > indicator that receivers don't process but that categorizes nodes in > an ill-defined way. In fact, of the five possible settings Bruce > listed, I don't know what two of them ("peer optimization" and "client > optimization") mean, and one distinction (neighbor versus routing > table) only makes sense with specific overlays, and so properly > belongs at the Topology Plugin Layer. The terms were explained in the email I sent out prior to that one. Were we to add such a field, I think the exact values that it should have would be a matter that required some thought. (I at first considered adding an overlay-specific bit, but since clients don't need to implement the full overlay algorithm decided it would be better to focus on more general concepts.) Regardless, after further thought I believe that something more like ForwardingOption with comprehension required/optional would be far more useful. Bruce From wang.jun17@zte.com.cn Sun Jul 12 18:30:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13C63A67FF; Sun, 12 Jul 2009 18:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.435 X-Spam-Level: X-Spam-Status: No, score=-94.435 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEm3YOSnvyDE; Sun, 12 Jul 2009 18:30:30 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 432C53A6975; Sun, 12 Jul 2009 18:30:28 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91103559614510; Mon, 13 Jul 2009 09:18:02 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 12012.5663799447; Mon, 13 Jul 2009 09:23:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6D1URRm070464; Mon, 13 Jul 2009 09:30:27 +0800 (CST) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: <7d6b50690907112100j61fb7088y82c41ce67dd25f4c@mail.gmail.com> To: lichun li MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Mon, 13 Jul 2009 09:30:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-13 09:30:16, Serialize complete at 2009-07-13 09:30:16 Content-Type: multipart/alternative; boundary="=_alternative 0008473A482575F2_=" X-MAIL: mse1.zte.com.cn n6D1URRm070464 Cc: p2psip@ietf.org, p2psip-bounces@ietf.org Subject: Re: [P2PSIP] New draft on content sharing usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 01:30:31 -0000 This is a multipart message in MIME format. --=_alternative 0008473A482575F2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIGxpDQogICBJbiB0aGlzIGRyYWZ0LCBwcm92aWRlcidzIHNlcnZlcnMgYXJlIHByZWZlcmFi bGUgdG8gZm9ybSB0aGUgb3ZlcmxheS4gDQpVc2VycyBjYW4gcHV0IHNvbWUgY29udGVudCBpbnRv IHRoaXMgUkVMT0FEIGJhc2VkIG92ZXJsYXksIGJ1dCBiZWZvcmUgDQp0aGF0LCB0aGUgc2VjdXJp dHkgbXVzdCBiZSBndWFyYW50ZWVkLg0KICAgSSB0b3RhbGx5IGFncmVlIHRoYXQgdGhlIFJFTE9B RCBiYXNlZCBvdmVybGF5IGFjdHMgYXMgbm90IG9ubHkgYSBDRE4gDQpidXQgYWxzbyBhIGNvbnRl bnQgc3RvcmFnZSBzZXJ2ZXIuIEFzIGZvciBzdG9yaW5nIHRoZSB1c2VyIGxpc3Qgb3IgdXNlciAN CnByb2ZpbGVzLCBJIHRoaW5rICBhbiBleGlzdGluZyBvdmVybGF5IGNvdWxkIGJlIHVzZWQgdG8g ZG8gdGhpcywgZS5nLiwgdGhlIA0KZXhpc3RpbmcgcDJwIGJhc2VkIHN1YnNjcmliZXIgZGF0YWJh c2UuDQoNCg0KICAgIFdhbmcgSnVuKFJ1c3NlbGwgV2FuZykNCg0KDQoNCg0KDQoNCmxpY2h1biBs aSA8bGlsaWNodW5AZ21haWwuY29tPiANCreivP7IyzogIHAycHNpcC1ib3VuY2VzQGlldGYub3Jn DQoyMDA5LTA3LTEyIDEyOjAwDQoNCsrVvP7Iyw0Kc2hlbi5qaW9uZ0B6dGUuY29tLmNuDQqzrcvN DQpwMnBzaXBAaWV0Zi5vcmcNCtb3zOINClJlOiBbUDJQU0lQXSBOZXcgZHJhZnQgb24gY29udGVu dCBzaGFyaW5nIHVzYWdlIGZvciBSRUxPQUQNCg0KDQoNCg0KDQoNCkludGVyZXN0aW5nLiBJIHRo aW5rIHdlIG1heSBzdGFydCBjb25zaWRlcmluZyB1c2luZyBSRUxPQUQgZm9yDQphcHBsaWNhdGlv bnMgb3RoZXIgdGhhbiBQMlBTSVAuIFNvbWUgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBhcmUgYmVs b3cuDQoNCkl0IHNlZW1zIHRoYXQgYWxsIHRoZSBjb250ZW50cyBhcmUgcHJvdmlkZWQgYnkgc2Vy dmljZSBwcm92aWRlci4gQ2FuDQp1c2VycyB1cGxvYWQgYW5kIHNoYXJlIGNvbnRlbnRzPw0KDQpT ZXJ2ZXJzIG9yIHVzZXIgUENzIGZvcm0gdGhlIHRoZSBSRUxPQUQgb3ZlcmxheSBmb3IgY29udGVu dCBzaGFyaW5nPw0KDQpJIHRoaW5rIHRoZSBSRUxPQUQgb3ZlcmxheSBpcyBtb3JlIHRoYW4gYSBD RE4uIENETiBpcyBub3QgcmVzcG9uc2libGUNCmZvciBkYXRhIGR1cmFiaWxpdHkgYnV0IHRyYWZm aWMgbG9jYWxpemF0aW9uLg0KREhUIG92ZXJsYXkgY2FuIGFzc3VyZSBkYXRhIGR1cmFiaWxpdHks IGFuZCB0aGlzIGRyYWZ0IGFkZHMgQ0RODQpmdW5jdGlvbiB0byBSRUxPQUQuDQpPdGhlciB0aGFu IHN0b3JlIGZpbGVzLCB0aGUgUkVMT0FEIG92ZXJsYXkgbWF5IHN0b3JlIHVzZXIgbGlzdCBmb3IN CnVwLWxheWVyIGRpc3RyaWJ1dGVkIHRyYWNrZXIgZnVuY3Rpb24uDQoNClNvIEkgdGhpbmsgdGhl IFJFTE9BRCBvdmVybGF5IG1heSBoYXZlIHRocmVlIGZ1bmN0aW9uczogQ0ROLCBmaWxlDQpzdG9y aW5nIGFuZCB1c2VyIGxpc3Qgc3RvcmluZy4NClRoZSBSRUxPQUQgb3ZlcmxheSBtYXkgcHJvdmlk ZSBhbGwgdGhyZWUgZnVuY3Rpb25zIHRvIHNvbWUgY29udGVudHMNCihlLmcuIGNvbnRlbnQgcHJv dmlkZWQgYnkgc2VydmljZSBwcm92aWRlcikNCmFuZCBvbmx5IHBhcnQgZnVuY3Rpb25zIHRvIG90 aGVyIGNvbnRlbnRzIChlLmcuIGNvbnRlbnRzIHByb3ZpZGVkIGJ5IA0KdXNlcnMpLg0KDQoNCg0K T24gV2VkLCBKdWwgMSwgMjAwOSBhdCA5OjE2IEFNLCA8c2hlbi5qaW9uZ0B6dGUuY29tLmNuPiB3 cm90ZToNCj4NCj4gSGkgYWxsLA0KPg0KPiBXZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IG9uIGNv bnRlbnQgc2hhcmluZyB1c2FnZSBmb3IgUkVMT0FELiBJdCANCnByb3ZpZGVzDQo+IHRoZSBmdW5j dGlvbmFsaXR5IG9mIGRpc3RyaWJ1dGluZyBhbmQgZmV0Y2hpbmcgc2hhcmVkIGNvbnRlbnQgDQpl ZmZpY2llbnRseSB0bw0KPiBhbmQgZnJvbSBhIFAyUCBvdmVybGF5IG5ldHdvcmssIHdoaWNoIHBl cmZvcm1zIGFzIENvbnRlbnQgRGVsaXZlcnkgDQpOZXR3b3JrDQo+IGFuZCBpcyBzZXJ2aWNlIGlu c2Vuc2l0aXZlLg0KPg0KPiBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0DQo+IA0KaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2hlbi1wMnBzaXAtY29udGVudC1zaGFy aW5nLTAwLnR4dA0KLg0KPiAgQ29tbWVudHMgYXJlIHdlbGNvbWUuDQo+DQo+DQo+IFRoYW5rcywN Cj4gSmlvbmcNCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkg b2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMg Y29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFp bnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQo+IA0KVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9t IHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KPiANClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBQMlBTSVAgbWFpbGluZyBsaXN0DQo+IFAy UFNJUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ay cHNpcA0KPg0KPg0KDQoNCg0KLS0gDQpTaW5jZXJlbHkgeW91cnMsDQoNCkxpY2h1biBMaQ0KTW9i aWxlIExpZmUgTmV3IE1lZGlhIExhYiwgQlVQVA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClAyUFNJUCBtYWlsaW5nIGxpc3QNClAyUFNJUEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg0KDQoNCg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdh bml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBp ZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFy ZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmlj YXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdp dGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBv cmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVz c2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhh cyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0 ZW0uDQo= --=_alternative 0008473A482575F2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBsaTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0luIHRoaXMgZHJhZnQs IHByb3ZpZGVyJ3MNCnNlcnZlcnMgYXJlIHByZWZlcmFibGUgdG8gZm9ybSB0aGUgb3ZlcmxheS4g VXNlcnMgY2FuIHB1dCBzb21lIGNvbnRlbnQNCmludG8gdGhpcyBSRUxPQUQgYmFzZWQgb3Zlcmxh eSwgYnV0IGJlZm9yZSB0aGF0LCB0aGUgc2VjdXJpdHkgbXVzdCBiZSBndWFyYW50ZWVkLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0kgdG90 YWxseSBhZ3JlZSB0aGF0IHRoZQ0KUkVMT0FEIGJhc2VkIG92ZXJsYXkgYWN0cyBhcyBub3Qgb25s eSBhIENETiBidXQgYWxzbyBhIGNvbnRlbnQgc3RvcmFnZQ0Kc2VydmVyLiBBcyBmb3Igc3Rvcmlu ZyB0aGUgdXNlciBsaXN0IG9yIHVzZXIgcHJvZmlsZXMsIEkgdGhpbmsgJm5ic3A7YW4NCmV4aXN0 aW5nIG92ZXJsYXkgY291bGQgYmUgdXNlZCB0byBkbyB0aGlzLCBlLmcuLCB0aGUgZXhpc3Rpbmcg cDJwIGJhc2VkDQpzdWJzY3JpYmVyIGRhdGFiYXNlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDtXYW5nIEp1bihSdXNz ZWxsIFdhbmcpPGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPmxpY2h1biBsaSAmbHQ7bGlsaWNodW5AZ21haWwuY29t Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8 /sjLOiAmbmJzcDtwMnBzaXAtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA3LTEyIDEyOjAwPC9mb250Pg0KPHRkIHdpZHRoPTcz JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnNoZW4uamlvbmdAenRlLmNvbS5j bjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+cDJwc2lwQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW1AyUFNJUF0gTmV3IGRyYWZ0IG9uIGNvbnRlbnQgc2hhcmluZw0KdXNhZ2UgZm9yIFJFTE9B RDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+SW50ZXJlc3RpbmcuIEkgdGhpbmsgd2UgbWF5IHN0YXJ0IGNvbnNpZGVyaW5nIHVzaW5nDQpS RUxPQUQgZm9yPGJyPg0KYXBwbGljYXRpb25zIG90aGVyIHRoYW4gUDJQU0lQLiBTb21lIHF1ZXN0 aW9ucyBhbmQgY29tbWVudHMgYXJlIGJlbG93Ljxicj4NCjxicj4NCkl0IHNlZW1zIHRoYXQgYWxs IHRoZSBjb250ZW50cyBhcmUgcHJvdmlkZWQgYnkgc2VydmljZSBwcm92aWRlci4gQ2FuPGJyPg0K dXNlcnMgdXBsb2FkIGFuZCBzaGFyZSBjb250ZW50cz88YnI+DQo8YnI+DQpTZXJ2ZXJzIG9yIHVz ZXIgUENzIGZvcm0gdGhlIHRoZSBSRUxPQUQgb3ZlcmxheSBmb3IgY29udGVudCBzaGFyaW5nPzxi cj4NCjxicj4NCkkgdGhpbmsgdGhlIFJFTE9BRCBvdmVybGF5IGlzIG1vcmUgdGhhbiBhIENETi4g Q0ROIGlzIG5vdCByZXNwb25zaWJsZTxicj4NCmZvciBkYXRhIGR1cmFiaWxpdHkgYnV0IHRyYWZm aWMgbG9jYWxpemF0aW9uLjxicj4NCkRIVCBvdmVybGF5IGNhbiBhc3N1cmUgZGF0YSBkdXJhYmls aXR5LCBhbmQgdGhpcyBkcmFmdCBhZGRzIENETjxicj4NCmZ1bmN0aW9uIHRvIFJFTE9BRC48YnI+ DQpPdGhlciB0aGFuIHN0b3JlIGZpbGVzLCB0aGUgUkVMT0FEIG92ZXJsYXkgbWF5IHN0b3JlIHVz ZXIgbGlzdCBmb3I8YnI+DQp1cC1sYXllciBkaXN0cmlidXRlZCB0cmFja2VyIGZ1bmN0aW9uLjxi cj4NCjxicj4NClNvIEkgdGhpbmsgdGhlIFJFTE9BRCBvdmVybGF5IG1heSBoYXZlIHRocmVlIGZ1 bmN0aW9uczogQ0ROLCBmaWxlPGJyPg0Kc3RvcmluZyBhbmQgdXNlciBsaXN0IHN0b3JpbmcuPGJy Pg0KVGhlIFJFTE9BRCBvdmVybGF5IG1heSBwcm92aWRlIGFsbCB0aHJlZSBmdW5jdGlvbnMgdG8g c29tZSBjb250ZW50czxicj4NCihlLmcuIGNvbnRlbnQgcHJvdmlkZWQgYnkgc2VydmljZSBwcm92 aWRlcik8YnI+DQphbmQgb25seSBwYXJ0IGZ1bmN0aW9ucyB0byBvdGhlciBjb250ZW50cyAoZS5n LiBjb250ZW50cyBwcm92aWRlZCBieSB1c2VycykuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24g V2VkLCBKdWwgMSwgMjAwOSBhdCA5OjE2IEFNLCAmbHQ7c2hlbi5qaW9uZ0B6dGUuY29tLmNuJmd0 OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBhbGwsPGJyPg0KJmd0Ozxicj4NCiZndDsg V2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdCBvbiBjb250ZW50IHNoYXJpbmcgdXNhZ2UgZm9yIFJF TE9BRC4gSXQNCnByb3ZpZGVzPGJyPg0KJmd0OyB0aGUgZnVuY3Rpb25hbGl0eSBvZiBkaXN0cmli dXRpbmcgYW5kIGZldGNoaW5nIHNoYXJlZCBjb250ZW50IGVmZmljaWVudGx5DQp0bzxicj4NCiZn dDsgYW5kIGZyb20gYSBQMlAgb3ZlcmxheSBuZXR3b3JrLCB3aGljaCBwZXJmb3JtcyBhcyBDb250 ZW50IERlbGl2ZXJ5DQpOZXR3b3JrPGJyPg0KJmd0OyBhbmQgaXMgc2VydmljZSBpbnNlbnNpdGl2 ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0PGJyPg0KJmd0 OyBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zaGVuLXAycHNpcC1j b250ZW50LXNoYXJpbmctMDAudHh0Ljxicj4NCiZndDsgJm5ic3A7Q29tbWVudHMgYXJlIHdlbGNv bWUuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IEppb25n PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUmbmJzcDtJbmZvcm1h dGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9u Jm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7 c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7 b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fi b3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3Nl Y3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZu YnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuPGJyPg0KJmd0OyBUaGlzJm5ic3A7 ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7 d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50 ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hv bSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJz cDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vy cm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNw O29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJl c3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci48YnI+DQomZ3Q7IFRo aXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3Im bmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50 aS1TcGFtJm5ic3A7c3lzdGVtLjxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBQMlBTSVAgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyBQMlBTSVBAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQotLSA8YnI+DQpTaW5jZXJlbHkgeW91cnMsPGJyPg0KPGJyPg0KTGljaHVu IExpPGJyPg0KTW9iaWxlIExpZmUgTmV3IE1lZGlhIExhYiwgQlVQVDxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUDJQU0lQIG1haWxpbmcg bGlzdDxicj4NClAyUFNJUEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcDJwc2lwPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHBy ZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNw O1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5i c3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVu dHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8m bmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJz cDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMm bmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMu DQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5z bWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7 YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2Um bmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNw O3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYm bmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJz cDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3Jp Z2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3 cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUm bmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4N ClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtm b3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7 QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0008473A482575F2_=-- From ligangyf@chinamobile.com Sun Jul 12 18:46:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2414C28C1DD for ; Sun, 12 Jul 2009 18:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.038 X-Spam-Level: ** X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56mvtgPl4x3N for ; Sun, 12 Jul 2009 18:46:54 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id DBA373A6B75 for ; Sun, 12 Jul 2009 18:46:53 -0700 (PDT) Received: from frank ([10.2.2.108]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2009071309471119-2747 ; Mon, 13 Jul 2009 09:47:11 +0800 From: "Li Gang" To: References: Date: Mon, 13 Jul 2009 09:47:15 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcoAPZLMdwRzTlMRR0eo7fStJ5VLUgDHjh/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-07-13 09:47:11, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-07-13 09:47:25, Serialize complete at 2009-07-13 09:47:25 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01CA039E.E766A3A0" Subject: [P2PSIP] Traffic localization for RELOAD - for comments X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 01:46:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01CA039E.E766A3A0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="gb2312" Hi, all, I submitted a draft about traffic localization for RELOAD, and the abstract is as follows: Hope you can take a few minutes to look at it and let me know your comments :-) Abstract: This document describes the traffic problems due to randomly distributed data storage in P2PSIP overlay, identifies the traffic localization requirements, and then proposes an overlay construction and data storage mechanism to implement traffic localization for REsource LOcation And Discovery (RELOAD). Specifically, it's proposed to add location indicator to the Peer node ID, for example, the beginning 5 bit hash ID stands for the peer location, and user data with the location indication shall be possible to be stored in local peer, thus to achieve traffic localization, reduce backbone network traffic, and improve the efficiency and QoS of the whole network. You can refer to the following link for more details: http://tools.ietf.org/html/draft-li-p2psip-localization-00 Really appreciate your comments and feedback, Li Gang China Mobile ------=_NextPart_000_00A5_01CA039E.E766A3A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

Hi, all,

 

I submitted a draft about traffic localization = for RELOAD, and the abstract is as follows:

Hope you can take a few minutes to look at it = and let me know your comments J

 

Abstract:

This document describes the traffic problems = due to randomly distributed data storage in P2PSIP overlay, identifies the = traffic localization requirements, and then proposes an overlay construction and = data storage mechanism to implement traffic localization for REsource = LOcation And Discovery (RELOAD). Specifically, it's proposed to add location = indicator to the Peer node ID, for example, the beginning 5 bit hash ID stands for = the peer location, and user data with the location indication shall be possible = to be stored in local peer, thus to achieve traffic localization, reduce = backbone network traffic, and improve the efficiency and QoS of the whole = network.

 

You can refer to the following link for more = details:

http:= //tools.ietf.org/html/draft-li-p2psip-localization-00

 

Really appreciate your comments and = feedback,

 

Li Gang

China Mobile

 

------=_NextPart_000_00A5_01CA039E.E766A3A0-- From lilichun@gmail.com Sun Jul 12 19:41:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7516C3A67AF; Sun, 12 Jul 2009 19:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyxAiAB4eBw4; Sun, 12 Jul 2009 19:41:02 -0700 (PDT) Received: from mail-gx0-f215.google.com (mail-gx0-f215.google.com [209.85.217.215]) by core3.amsl.com (Postfix) with ESMTP id 534D73A6827; Sun, 12 Jul 2009 19:41:02 -0700 (PDT) Received: by gxk11 with SMTP id 11so2036998gxk.13 for ; Sun, 12 Jul 2009 19:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nub0BwMD/q/KO2ewbxqvfzehW6Bdd+ZzZ3u5Y3LdbhU=; b=eOmivCE7KDRW4jjgFkmmK6bF3SaUoDBIPrK08hRYvDjWsI2sYHd1DLzGLnG7WG82Jm dfEQZL5bX1d1YmQy+BBA6O2yEerkhsBecUHjrUl862OmltAyXQcMAKmwejmmjPovFjuo 1RyY0UAfZvcz6N9rpmlMfQn/i9qy35zuE/GsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tWqvcvkdubjRKMvqSHlI8cb8s2BxQG5mWvgy/hk5NXfx51R5Uv8krYl6f0jje7Ojnp mHmuEIFEK4rdnVTVnEt3CZgVyOLMjJJEGdiXTMx9aebuxjFIHGE0veXD8bEX15lDaSEK VEob+WHrpdoJ6eVUJb5Cd11nTlXA8bLlEw0Ug= MIME-Version: 1.0 Received: by 10.150.156.9 with SMTP id d9mr7070458ybe.326.1247452890645; Sun, 12 Jul 2009 19:41:30 -0700 (PDT) In-Reply-To: References: <7d6b50690907112100j61fb7088y82c41ce67dd25f4c@mail.gmail.com> Date: Mon, 13 Jul 2009 10:41:30 +0800 Message-ID: <7d6b50690907121941x72413faag39a3b241b6163c3e@mail.gmail.com> From: lichun li To: wang.jun17@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org, p2psip-bounces@ietf.org Subject: Re: [P2PSIP] New draft on content sharing usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 02:41:03 -0000 2009/7/13 : > > Hi, li > In this draft, provider's servers are preferable to form the overlay. > Users can put some content into this RELOAD based overlay, but before tha= t, > the security must be guaranteed. > I totally agree that the RELOAD based overlay acts as not only a CDN b= ut > also a content storage server. As for storing the user list or user > profiles, I think an existing overlay could be used to do this, e.g., th= e > existing p2p based subscriber database. So there are two overlays? Are there any interactions between two overlays? > > > Wang Jun(Russell Wang) > > > > > > lichun li > =B7=A2=BC=FE=C8=CB: p2psip-bounces@ietf.org > > 2009-07-12 12:00 > > =CA=D5=BC=FE=C8=CB > shen.jiong@zte.com.cn > =B3=AD=CB=CD > p2psip@ietf.org > =D6=F7=CC=E2 > Re: [P2PSIP] New draft on content sharing usage for RELOAD > > > > > Interesting. I think we may start considering using RELOAD for > applications other than P2PSIP. Some questions and comments are below. > > It seems that all the contents are provided by service provider. Can > users upload and share contents? > > Servers or user PCs form the the RELOAD overlay for content sharing? > > I think the RELOAD overlay is more than a CDN. CDN is not responsible > for data durability but traffic localization. > DHT overlay can assure data durability, and this draft adds CDN > function to RELOAD. > Other than store files, the RELOAD overlay may store user list for > up-layer distributed tracker function. > > So I think the RELOAD overlay may have three functions: CDN, file > storing and user list storing. > The RELOAD overlay may provide all three functions to some contents > (e.g. content provided by service provider) > and only part functions to other contents (e.g. contents provided by user= s). > > > > On Wed, Jul 1, 2009 at 9:16 AM, wrote: >> >> Hi all, >> >> We have submitted a draft on content sharing usage for RELOAD. It provid= es >> the functionality of distributing and fetching shared content efficientl= y >> to >> and from a P2P overlay network, which performs as Content Delivery Netwo= rk >> and is service insensitive. >> >> The draft can be found at >> >> http://www.ietf.org/internet-drafts/draft-shen-p2psip-content-sharing-00= .txt. >> Comments are welcome. >> >> >> Thanks, >> Jiong >> >> >> -------------------------------------------------------- >> >> ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is= confidential. Recipients named above are obligated to maintain secrecy and= are not permitted to disclose the contents of this communication to others= . >> >> This email and any files transmitted with it are confidential and intend= ed solely for the use of the individual or entity to whom they are addresse= d. If you have received this email in error please notify the originator of= the message. Any views expressed in this message are those of the individu= al sender. >> >> This message has been scanned for viruses and Spam by ZTE Anti-Spam syst= em. >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> > > > > -- > Sincerely yours, > > Lichun Li > Mobile Life New Media Lab, BUPT > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT From lilichun@gmail.com Sun Jul 12 19:46:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEB63A6A38 for ; Sun, 12 Jul 2009 19:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAM4-PTvrVyp for ; Sun, 12 Jul 2009 19:46:31 -0700 (PDT) Received: from mail-gx0-f215.google.com (mail-gx0-f215.google.com [209.85.217.215]) by core3.amsl.com (Postfix) with ESMTP id A48EF3A69A6 for ; Sun, 12 Jul 2009 19:46:28 -0700 (PDT) Received: by gxk11 with SMTP id 11so2040606gxk.13 for ; Sun, 12 Jul 2009 19:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H99O1/POUEOSgXjXg9wjKQF3zIDOdIpC0KXu7/turjw=; b=jmAIW1/1XlsiUQNHiS1nswmrK9lP6qeveGUedhvywQcGLCnShWVa4nVIe2SzyRjLlK yDJZE8ThQsh4AWiX1iIVCSeRJ1cn0lgeq+GrmXNYK7cK6eC9ZYhIYhKv3T2EMnRjqxi3 3nHzbfjWEelEm1Etdl69G7VEkrTf2fzsgwNSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GbfuXd3mVHVxsSYq4jL+x1OgpHo1duhArDwntVMDGeaDfhNCOkclUVrIgYwGNPyJsH K7AgbTyeyTeqtw+Xo9hnmvEleHNAfPV3h/Sr6iE4lFWqBps9qCmViQPlJohIS7WAze9v Od4w5BwB8ibj4dR78ao/BnzAvKI7R1FpSKxmM= MIME-Version: 1.0 Received: by 10.151.156.10 with SMTP id i10mr7145749ybo.176.1247453214699; Sun, 12 Jul 2009 19:46:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Jul 2009 10:46:54 +0800 Message-ID: <7d6b50690907121946x69fc19a0s39a3f0ddbe56a2fe@mail.gmail.com> From: lichun li To: shen.jiong@zte.com.cn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] New draft on content sharing usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 02:46:31 -0000 Section 9 "Overlay Optimize Example" is interesting. Can you give more details about the multi-domain overlay architecture? For example, which content is stored in which domain? On Wed, Jul 1, 2009 at 9:16 AM, wrote: > > Hi all, > > We have submitted a draft on content sharing usage for RELOAD. It provide= s > the functionality of distributing and fetching shared content efficiently= to > and from a P2P overlay network, which performs as Content Delivery Networ= k > and is service insensitive. > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-shen-p2psip-content-sharing-00.= txt. > =A0Comments are welcome. > > > Thanks, > Jiong > > > -------------------------------------------------------- > ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0= in=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organizat= ion.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0name= d=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=A0p= ermitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=A0to= =A0others. > This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confid= ential=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual= =A0or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0re= ceived=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0o= f=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0= those=A0of=A0the=A0individual=A0sender. > This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by= =A0ZTE=A0Anti-Spam=A0system. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT From llf.bbi001@gmail.com Sun Jul 12 22:21:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F973A6840 for ; Sun, 12 Jul 2009 22:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.905 X-Spam-Level: ** X-Spam-Status: No, score=2.905 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta8yAQQ5Txgh for ; Sun, 12 Jul 2009 22:21:18 -0700 (PDT) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by core3.amsl.com (Postfix) with ESMTP id C77643A67D8 for ; Sun, 12 Jul 2009 22:21:18 -0700 (PDT) Received: by pzk14 with SMTP id 14so1518307pzk.32 for ; Sun, 12 Jul 2009 22:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=MyTAUemR0e6MNrNK6ffd4nYu6fRSJy0NT1J5Vs8MnYQ=; b=HUDuZEdC4YuDDfsuNuQLtBpK6wx2Of5GwDWz7I/McE0/w/7/TilI/EcPptUpkBrzxq 09d4y0ulspQMmki9j0tI7m8DRe0IL0/54PjBM6lc3tHy/LwCd/+1IeHB0cSpedSUQpxs Sapj0AYQvtnusqrHmVTHXsfwbpUskKKiRl0xE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=S+fkKcUjNhRNqZ9oaGJG+bbZAJNjZBUSqT5Kpu17xUAJpXbzxuPL1024Hi1qnbP4yk l/fhPvwqJGB4Um4TdT/u9C4PiG7uA1DR3BxuHXoj+Vv02WWzsAVPSrqrqvOqCABd91YS ENme83qb23SXZjSbds13mfJcOpJbWzJDHBlh4= MIME-Version: 1.0 Received: by 10.142.229.6 with SMTP id b6mr1171104wfh.88.1247462500739; Sun, 12 Jul 2009 22:21:40 -0700 (PDT) Date: Mon, 13 Jul 2009 13:21:40 +0800 Message-ID: <137817610907122221r75c21f5foa50450723898184c@mail.gmail.com> From: =?GB2312?B?wNbA+7fm?= To: p2psip@ietf.org Content-Type: multipart/alternative; boundary=000e0cd32c483a2a7e046e8f7f9b Subject: [P2PSIP] p2psip-hierachical-p2psip-overlay X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 05:21:19 -0000 --000e0cd32c483a2a7e046e8f7f9b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all , Welcome to comment on the draft "p2psip-hierachical-p2psip-overlay", http://tools.ietf.org/id/draft-le-p2psip-hierachical-p2psip-overlay-00.txt. My personal view is that it's time to consider Node heterogeneity in P2P SIP system in order to enhance the performance. This draft discusses the hierarchical overlay architecture in Peer- to-Peer (P2P) SIP system. The P2P SIP is defined as a distributed network and each peer is equal in it. But actually peers are different from each other on many aspects, e.g., physical performance, network performance or system performance (e.g., uptime). So node heterogeneity should been considered enough in P2P SIP system, which affects the scalability and service availability of P2P SIP overlays. This draft introduces the performance concerns of P2P SIP overlay without consideration of node heterogeneity at first. After that, an alternative architecture of hierarchical P2P SIP overlay is brought up. Best Regards! Le-Lifeng cmcc --000e0cd32c483a2a7e046e8f7f9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear=A0 all=A0 ,=20
Welcome to comment on the draft "p2psip-hierachical-p2psip-overla= y",
http://tools.iet= f.org/id/draft-le-p2psip-hierachical-p2psip-overlay-00.txt.
My personal view is that it's time to consider Node heterogeneity = in P2P SIP system in order to enhance the performance.
This draft discusses the hierarchical overlay architecture in Peer-=A0=A0 to-Peer (P2P) SIP system. The P2P SIP is defined as a distributed=A0=A0 network and each peer is equal in it. But actually peers are
= =A0=A0 different from each other on many aspects, e.g., physical performanc= e,
=A0=A0 network performance or system performance (e.g., uptime). So node=A0=A0 heterogeneity should been considered enough in P2P SIP system, whic= h
=A0=A0 affects the scalability and service availability of P2P SIP ove= rlays.
=A0=A0 This draft introduces the performance concerns of P2P SIP overlay=A0=A0 without consideration of node heterogeneity at first. After that, a= n
=A0=A0 alternative architecture of hierarchical P2P SIP overlay is bro= ught
=A0=A0 up.
=A0
Best Regards!
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 =A0 =A0 =A0 =A0 Le-Lifeng
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0 cmcc
--000e0cd32c483a2a7e046e8f7f9b-- From gao.yang2@zte.com.cn Sun Jul 12 23:44:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5A03A67DB for ; Sun, 12 Jul 2009 23:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.719 X-Spam-Level: X-Spam-Status: No, score=-97.719 tagged_above=-999 required=5 tests=[AWL=-1.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, J_CHICKENPOX_62=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8UHZekY8ml7 for ; Sun, 12 Jul 2009 23:44:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 370713A69D8 for ; Sun, 12 Jul 2009 23:44:53 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111642075036648; Mon, 13 Jul 2009 14:28:11 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 89631.2391261503; Mon, 13 Jul 2009 14:37:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6D6jASf048377; Mon, 13 Jul 2009 14:45:11 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: "Li Gang" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 13 Jul 2009 14:44:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-13 14:44:53, Serialize complete at 2009-07-13 14:44:53 Content-Type: multipart/alternative; boundary="=_alternative 0025121A482575F2_=" X-MAIL: mse2.zte.com.cn n6D6jASf048377 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Traffic localization for RELOAD - for comments X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 06:44:56 -0000 This is a multipart message in MIME format. --=_alternative 0025121A482575F2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkZpcnN0LCBJIGFtIHJlYWxseSBnbGFkIHRvIHNlZSBhIGRyYWZ0IG9uIHRoZSB0b3Bp YyBvZiAqTG9jYWxpdHkqIGZvciANClJFTE9BRC4gSW4gZmFjdCwgY29uc2lkZXJpbmcgbG9jYWxp emF0aW9uIGlzIGltcG9ydGFudCBmb3IgbmV0d29yayANCm9wZXJhdG9yIHdoaWxlIHVzaW5nIHAy cCB3YXkuDQoNClRoZXJlIGFyZSBzb21lIGNvbW1lbnRzL2RvdWJ0czoNCg0KMS4gV2h5IHB1dCAz LjMocHJvcG9zYWwpIGluIHRoZSAqUmVxdWlyZW1lbnRzKiBjaGFwdGVyPw0KQW5kIGlmIHlvdSB3 YW50IGdpdmluZyB0aGUgZmluYWwgc29sdXRpb24gaW4gdGhlIHNhbWUgZHJhZnQsIEkgdGhpbmsg dGhhdCANCnRoZSAzLjMocHJvcG9zYWwpIG5lZWQgZW5yaWNoZWQgdG8gYmUgY29udmluY2luZy4g RnVydGhlciwgSSB0aGluayBzcGxpdCANCnRoZSBvbmUgaW50byB0d28gb3IgbW9yZSBkcmFmdHMg bWF5IGJlIGJldHRlci4gVGhlIGZpcnN0IG9uZSBjYW4gDQpjb25jZW50cmF0ZSBvbiB0aGUgKlJl cXVpcmVtZW50cyogYW5kICpNZXRyaWNzL01lYXN1cmVtZW50Ki4gQW5kIHNlcGFyYXRlZCANCmRy YWZ0cyhpbiBmYWN0LCB0aGUgc29sdXRpb24gY2FuIGJlIG1vcmUgdGhhbiBvbmUpIGZvciBwcm9w b3NlZCBESFRzIA0KY29uc2lkZXJpbmcgbG9jYWxpemF0aW9uLiBFc3BlY2lhbGx5IGltcG9ydGFu dCB0aGluZyBpcyB0aGUgDQoqTWV0cmljcy9NZWFzdXJlbWVudCogd2hpY2ggaXMgdGhlIGVzdGlt YXRvciBmb3IgdGhlIHByb3Bvc2VkIERIVHMuDQoNCjIuIEl0IGlzIGJldHRlciB0byBhZGQgc29t ZSBlYXJseSBwYXBlciBhcyByZWZlcmVuY2UuDQpBcyB0aGUgc29sdXRpb24gaW4gMy4zKHByb3Bv c2FsKSB1c2UgdGhlIHdlbGwta25vd24gd2F5IG9mICpMb2NhdGlvbi1iYXNlZCANCk5vZGUgSUQq LCBpdCBpcyBiZXR0ZXIgdG8gYWRkIHNvbWUgZWFybHkgcGFwZXIod2hpY2ggaW50cm9kdWNpbmcg c3VjaCB3YXkpIA0KYXMgcmVmZXJlbmNlLg0KDQoNCkJUVywgQmVjYXVzZSAqbG9jYWxpemF0aW9u KiBpcyB2ZXJ5IGltcG9ydGFudCBmb3IgUW9TIGFuZCBvcGVyYXRpb24sIEkgDQpyZWFsbHkgd2Fu dCB0byBzZWUgdGhlIFdHIG1ha2luZyAqbG9jYWxpemF0aW9uKiBhcyBhIHJlc2VhcmNoIGRpcmVj dGlvbiANCmZvciBQMlBTSVAuDQoNClRoYW5rcy4NCg0KR2FvDQogDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQog VGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5j bg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCiJMaSBHYW5nIiA8 bGlnYW5neWZAY2hpbmFtb2JpbGUuY29tPiANCreivP7IyzogIHAycHNpcC1ib3VuY2VzQGlldGYu b3JnDQoyMDA5LTA3LTEzIDA5OjQ3DQoNCsrVvP7Iyw0KPHAycHNpcEBpZXRmLm9yZz4NCrOty80N Cg0K1vfM4g0KW1AyUFNJUF0gVHJhZmZpYyBsb2NhbGl6YXRpb24gZm9yIFJFTE9BRCAtIGZvciBj b21tZW50cw0KDQoNCg0KDQoNCg0KSGksIGFsbCwNCiANCkkgc3VibWl0dGVkIGEgZHJhZnQgYWJv dXQgdHJhZmZpYyBsb2NhbGl6YXRpb24gZm9yIFJFTE9BRCwgYW5kIHRoZSANCmFic3RyYWN0IGlz IGFzIGZvbGxvd3M6DQpIb3BlIHlvdSBjYW4gdGFrZSBhIGZldyBtaW51dGVzIHRvIGxvb2sgYXQg aXQgYW5kIGxldCBtZSBrbm93IHlvdXIgDQpjb21tZW50cyBKDQogDQpBYnN0cmFjdDoNClRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB0cmFmZmljIHByb2JsZW1zIGR1ZSB0byByYW5kb21seSBk aXN0cmlidXRlZCANCmRhdGEgc3RvcmFnZSBpbiBQMlBTSVAgb3ZlcmxheSwgaWRlbnRpZmllcyB0 aGUgdHJhZmZpYyBsb2NhbGl6YXRpb24gDQpyZXF1aXJlbWVudHMsIGFuZCB0aGVuIHByb3Bvc2Vz IGFuIG92ZXJsYXkgY29uc3RydWN0aW9uIGFuZCBkYXRhIHN0b3JhZ2UgDQptZWNoYW5pc20gdG8g aW1wbGVtZW50IHRyYWZmaWMgbG9jYWxpemF0aW9uIGZvciBSRXNvdXJjZSBMT2NhdGlvbiBBbmQg DQpEaXNjb3ZlcnkgKFJFTE9BRCkuIFNwZWNpZmljYWxseSwgaXQncyBwcm9wb3NlZCB0byBhZGQg bG9jYXRpb24gaW5kaWNhdG9yIA0KdG8gdGhlIFBlZXIgbm9kZSBJRCwgZm9yIGV4YW1wbGUsIHRo ZSBiZWdpbm5pbmcgNSBiaXQgaGFzaCBJRCBzdGFuZHMgZm9yIA0KdGhlIHBlZXIgbG9jYXRpb24s IGFuZCB1c2VyIGRhdGEgd2l0aCB0aGUgbG9jYXRpb24gaW5kaWNhdGlvbiBzaGFsbCBiZSANCnBv c3NpYmxlIHRvIGJlIHN0b3JlZCBpbiBsb2NhbCBwZWVyLCB0aHVzIHRvIGFjaGlldmUgdHJhZmZp YyBsb2NhbGl6YXRpb24sIA0KcmVkdWNlIGJhY2tib25lIG5ldHdvcmsgdHJhZmZpYywgYW5kIGlt cHJvdmUgdGhlIGVmZmljaWVuY3kgYW5kIFFvUyBvZiB0aGUgDQp3aG9sZSBuZXR3b3JrLg0KIA0K WW91IGNhbiByZWZlciB0byB0aGUgZm9sbG93aW5nIGxpbmsgZm9yIG1vcmUgZGV0YWlsczoNCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXAycHNpcC1sb2NhbGl6YXRpb24tMDAN CiANClJlYWxseSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgYW5kIGZlZWRiYWNrLA0KIA0KTGkg R2FuZw0KQ2hpbmEgTW9iaWxlDQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClAyUFNJUCBtYWlsaW5nIGxpc3QNClAyUFNJUEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90 aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBj b25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBv ZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRo b3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0025121A482575F2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Rmlyc3QsIEkgYW0gcmVhbGx5IGdsYWQg dG8gc2VlIGEgZHJhZnQNCm9uIHRoZSB0b3BpYyBvZiAqTG9jYWxpdHkqIGZvciBSRUxPQUQuIElu IGZhY3QsIGNvbnNpZGVyaW5nIGxvY2FsaXphdGlvbg0KaXMgaW1wb3J0YW50IGZvciBuZXR3b3Jr IG9wZXJhdG9yIHdoaWxlIHVzaW5nIHAycCB3YXkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVyZSBhcmUgc29tZSBjb21tZW50cy9kb3VidHM6PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBXaHkgcHV0 IDMuMyhwcm9wb3NhbCkgaW4gdGhlICpSZXF1aXJlbWVudHMqDQpjaGFwdGVyPzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIGlmIHlvdSB3YW50IGdpdmluZyB0 aGUgZmluYWwgc29sdXRpb24NCmluIHRoZSBzYW1lIGRyYWZ0LCBJIHRoaW5rIHRoYXQgdGhlIDMu Myhwcm9wb3NhbCkgbmVlZCBlbnJpY2hlZCB0byBiZSBjb252aW5jaW5nLg0KRnVydGhlciwgSSB0 aGluayBzcGxpdCB0aGUgb25lIGludG8gdHdvIG9yIG1vcmUgZHJhZnRzIG1heSBiZSBiZXR0ZXIu IFRoZQ0KZmlyc3Qgb25lIGNhbiBjb25jZW50cmF0ZSBvbiB0aGUgKlJlcXVpcmVtZW50cyogYW5k ICpNZXRyaWNzL01lYXN1cmVtZW50Ki4NCkFuZCBzZXBhcmF0ZWQgZHJhZnRzKGluIGZhY3QsIHRo ZSBzb2x1dGlvbiBjYW4gYmUgbW9yZSB0aGFuIG9uZSkgZm9yIHByb3Bvc2VkDQpESFRzIGNvbnNp ZGVyaW5nIGxvY2FsaXphdGlvbi4gRXNwZWNpYWxseSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhlICpN ZXRyaWNzL01lYXN1cmVtZW50Kg0Kd2hpY2ggaXMgdGhlIGVzdGltYXRvciBmb3IgdGhlIHByb3Bv c2VkIERIVHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4yLiBJdCBpcyBiZXR0ZXIgdG8gYWRkIHNvbWUgZWFybHkgcGFwZXINCmFzIHJlZmVyZW5jZS48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIHRoZSBzb2x1dGlv biBpbiAzLjMocHJvcG9zYWwpIHVzZQ0KdGhlIHdlbGwta25vd24gd2F5IG9mICpMb2NhdGlvbi1i YXNlZCBOb2RlIElEKiwgaXQgaXMgYmV0dGVyIHRvIGFkZCBzb21lDQplYXJseSBwYXBlcih3aGlj aCBpbnRyb2R1Y2luZyBzdWNoIHdheSkgYXMgcmVmZXJlbmNlLjwvZm9udD4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlRXLCBCZWNhdXNlICpsb2NhbGl6 YXRpb24qIGlzIHZlcnkNCmltcG9ydGFudCBmb3IgUW9TIGFuZCBvcGVyYXRpb24sIEkgcmVhbGx5 IHdhbnQgdG8gc2VlIHRoZSBXRyBtYWtpbmcgKmxvY2FsaXphdGlvbioNCmFzIGEgcmVzZWFyY2gg ZGlyZWN0aW9uIGZvciBQMlBTSVAuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5UaGFua3MuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6 IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsg OigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxi cj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0y NiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0xpIEdhbmcmcXVvdDsg Jmx0O2xpZ2FuZ3lmQGNoaW5hbW9iaWxlLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7cDJwc2lwLWJvdW5jZXNAaWV0 Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNy0x MyAwOTo0NzwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4mbHQ7cDJwc2lwQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1AyUFNJUF0gVHJhZmZpYyBsb2NhbGl6 YXRpb24gZm9yIFJFTE9BRA0KLSBmb3IgY29tbWVudHM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0 YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4N Cjxicj4NCjxicj4NCjxkaXY+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5IaSwgYWxs LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkkgc3VibWl0dGVkIGEgZHJhZnQgYWJvdXQgdHJh ZmZpYyBsb2NhbGl6YXRpb24NCmZvciBSRUxPQUQsIGFuZCB0aGUgYWJzdHJhY3QgaXMgYXMgZm9s bG93czo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5Ib3BlIHlvdSBjYW4g dGFrZSBhIGZldyBtaW51dGVzIHRvIGxvb2sgYXQNCml0IGFuZCBsZXQgbWUga25vdyB5b3VyIGNv bW1lbnRzIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iV2luZ2RpbmdzIj5KPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+QWJzdHJhY3Q6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHRyYWZmaWMgcHJvYmxlbXMNCmR1ZSB0 byByYW5kb21seSBkaXN0cmlidXRlZCBkYXRhIHN0b3JhZ2UgaW4gUDJQU0lQIG92ZXJsYXksIGlk ZW50aWZpZXMNCnRoZSB0cmFmZmljIGxvY2FsaXphdGlvbiByZXF1aXJlbWVudHMsIGFuZCB0aGVu IHByb3Bvc2VzIGFuIG92ZXJsYXkgY29uc3RydWN0aW9uDQphbmQgZGF0YSBzdG9yYWdlIG1lY2hh bmlzbSB0byBpbXBsZW1lbnQgdHJhZmZpYyBsb2NhbGl6YXRpb24gZm9yIFJFc291cmNlDQpMT2Nh dGlvbiBBbmQgRGlzY292ZXJ5IChSRUxPQUQpLiBTcGVjaWZpY2FsbHksIGl0J3MgcHJvcG9zZWQg dG8gYWRkIGxvY2F0aW9uDQppbmRpY2F0b3IgdG8gdGhlIFBlZXIgbm9kZSBJRCwgZm9yIGV4YW1w bGUsIHRoZSBiZWdpbm5pbmcgNSBiaXQgaGFzaCBJRA0Kc3RhbmRzIGZvciB0aGUgcGVlciBsb2Nh dGlvbiwgYW5kIHVzZXIgZGF0YSB3aXRoIHRoZSBsb2NhdGlvbiBpbmRpY2F0aW9uDQpzaGFsbCBi ZSBwb3NzaWJsZSB0byBiZSBzdG9yZWQgaW4gbG9jYWwgcGVlciwgdGh1cyB0byBhY2hpZXZlIHRy YWZmaWMgbG9jYWxpemF0aW9uLA0KcmVkdWNlIGJhY2tib25lIG5ldHdvcmsgdHJhZmZpYywgYW5k IGltcHJvdmUgdGhlIGVmZmljaWVuY3kgYW5kIFFvUyBvZg0KdGhlIHdob2xlIG5ldHdvcmsuPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+WW91IGNhbiByZWZlciB0byB0aGUgZm9sbG93aW5nIGxp bmsgZm9yIG1vcmUNCmRldGFpbHM6PC9mb250Pg0KPGJyPjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXAycHNpcC1sb2NhbGl6YXRpb24tMDAiPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1saS1wMnBzaXAtbG9jYWxpemF0aW9uLTAwPC91PjwvZm9udD48L2E+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj5SZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIGNvbW1lbnRzIGFuZCBmZWVkYmFjayw8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5MaSBHYW5nPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+Q2hpbmEgTW9iaWxlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJB cmlhbCI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9Mj48dHQ+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpQMlBTSVAgbWFpbGluZyBsaXN0PGJyPg0K UDJQU0lQQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wMnBzaXA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj48L2Rpdj4NCjxicj48cHJlPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZu YnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7 aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5i c3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2Vu ZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25h bWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50 YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRl ZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5i c3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJz cDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJz cDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtp bnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3 aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZu YnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7 ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhw cmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3Nl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNw O21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3Zp cnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0m bmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0025121A482575F2_=-- From melodysong@huawei.com Sun Jul 12 23:45:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B243A6C88; Sun, 12 Jul 2009 23:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTXNQNNq352V; Sun, 12 Jul 2009 23:45:46 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0E8483A67DB; Sun, 12 Jul 2009 23:45:46 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMP00GSPK4JU0@szxga03-in.huawei.com>; Mon, 13 Jul 2009 14:45:55 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMP00MO1K4JWQ@szxga03-in.huawei.com>; Mon, 13 Jul 2009 14:45:55 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMP00IHHK4H5S@szxml04-in.huawei.com>; Mon, 13 Jul 2009 14:45:55 +0800 (CST) Date: Mon, 13 Jul 2009 14:45:53 +0800 From: Song Haibin In-reply-to: To: 'Bruce Lowekamp' , 'Eric Rescorla' Message-id: <026001ca0385$927b2c80$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoDNiu2nlsLvlfSR/a6WqsmP1geIAATAM1Q Cc: p2psip@ietf.org, p2psip-bounces@ietf.org Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 06:45:47 -0000 Bruce, I followed this thread and generally I like this option. It would be explicitly useful to identify client and peer operations. I'm a little confused why we should depend on the Update message to determine whether an attached node is a client or a peer. Thanks! Haibin >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >On Behalf Of Bruce Lowekamp >Sent: Monday, July 13, 2009 5:16 AM >To: Eric Rescorla >Cc: p2psip@ietf.org; p2psip-bounces@ietf.org >Subject: Re: [P2PSIP] Client operation in RELOAD > >On Sun, Jul 12, 2009 at 5:08 PM, Eric >Rescorla wrote: >> At Sun, 12 Jul 2009 20:54:14 +0000, >> David A. Bryan wrote: >>> >>> Actually this is more of a general comment that it is big >enough that >>> using it as an excuse to not include something isn't really a valid >>> reason. >> >> So you'll totally support it when I suggest we incorporate a feature >> to carry around BGP route tables? After all, we might need that >> someday and if the protocol is bloated already, no harm no foul, >> right? >> >> >>> My point is more that you saying "you don't like cruft" is >not a very >>> well articulated reason to not include a 16 bit field in an already >>> 141 page document. I think we have included enough that, this looks >>> to me as useful as many other things in the draft, and I personally >>> support it. >> >> Of course, you're just totally mischaracterizing what I said, which >> was: >> >> ? I don't see that this change adds any value. It's just >additional ? >> cruft. >> >> To be clear, my objection isn't just that I don't like cruft, but >> rather that this feature is useless. Actually, now that I >look at it, >> it's worse than useless, it's actively harmful; RELOAD >doesn't include >> clients as a first-class concept for a good reason, it's not >necessary >> and it interferes with the orthogonality of the protocol, which is >> almost never a good architectural decision. >> >> It's particularly bad in this case because we're adding an ad hoc >> indicator that receivers don't process but that categorizes nodes in >> an ill-defined way. In fact, of the five possible settings Bruce >> listed, I don't know what two of them ("peer optimization" >and "client >> optimization") mean, and one distinction (neighbor versus routing >> table) only makes sense with specific overlays, and so properly >> belongs at the Topology Plugin Layer. > >The terms were explained in the email I sent out prior to that one. >Were we to add such a field, I think the exact values that it >should have would be a matter that required some thought. (I >at first considered adding an overlay-specific bit, but since >clients don't need to implement the full overlay algorithm >decided it would be better to focus on more general concepts.) > >Regardless, after further thought I believe that something >more like ForwardingOption with comprehension >required/optional would be far more useful. > >Bruce >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > From Even.roni@huawei.com Sun Jul 12 23:59:14 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAE83A6C88 for ; Sun, 12 Jul 2009 23:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd-f5mgYM8Xb for ; Sun, 12 Jul 2009 23:59:13 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 88C213A6CAD for ; Sun, 12 Jul 2009 23:58:44 -0700 (PDT) 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 <0KMP00KFUKQGFU@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 13 Jul 2009 14:59:04 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMP00GP7KQGLZ@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 13 Jul 2009 14:59:04 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-100-175.red.bezeqint.net [79.182.100.175]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMP00ABBKQCMM@szxml01-in.huawei.com> for p2psip@ietf.org; Mon, 13 Jul 2009 14:59:04 +0800 (CST) Date: Mon, 13 Jul 2009 09:58:19 +0300 From: Roni Even To: p2psip@ietf.org Message-id: <082701ca0387$5057a570$f106f050$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_DHmgejKeMNywVzb+9C5KNg)" Content-language: en-us Thread-index: AcoDh01oL7bIvu53RomRn3KYTvxi0g== Subject: [P2PSIP] New version for draft-matuszewski-p2psip-security-requirements-05 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 06:59:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_DHmgejKeMNywVzb+9C5KNg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, There is a new draft on security for p2psip titled p2psip security overview and risk analysis in http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements-05 The document is similar to the previous version but based on the discussion in the previous meeting all the requirements were taken out and sent to the mailing list (sees thread discussion on security requirements). This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers. Thanks Roni Even --Boundary_(ID_DHmgejKeMNywVzb+9C5KNg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

There is a new draft on security for p2psip titled p2psip security overview and risk analysis in http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements-05

 

The document is similar to the previous version but based on the discussion in the previous meeting all the requirements were taken out and sent to the mailing list (sees thread discussion on security requirements).

This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network.  It discusses security threats for the P2PSIP architecture and its  components.  It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP  architecture into layers and analyzes the security issues in each layer and the security relationship among the layers.

Thanks

Roni Even

--Boundary_(ID_DHmgejKeMNywVzb+9C5KNg)-- From wang.jun17@zte.com.cn Mon Jul 13 00:41:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E833A6CF6; Mon, 13 Jul 2009 00:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.435 X-Spam-Level: X-Spam-Status: No, score=-94.435 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM5f1kf1EWe6; Mon, 13 Jul 2009 00:41:40 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 520CD28C153; Mon, 13 Jul 2009 00:41:39 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91103559614510; Mon, 13 Jul 2009 15:29:12 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 89631.5663799447; Mon, 13 Jul 2009 15:34:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6D7fuxS010635; Mon, 13 Jul 2009 15:41:56 +0800 (CST) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: <7d6b50690907121941x72413faag39a3b241b6163c3e@mail.gmail.com> To: lichun li MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Mon, 13 Jul 2009 15:41:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-13 15:41:37, Serialize complete at 2009-07-13 15:41:37 Content-Type: multipart/alternative; boundary="=_alternative 002A46AB482575F2_=" X-MAIL: mse2.zte.com.cn n6D7fuxS010635 Cc: p2psip@ietf.org, p2psip-bounces@ietf.org Subject: Re: [P2PSIP] New draft on content sharing usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 07:41:41 -0000 This is a multipart message in MIME format. --=_alternative 002A46AB482575F2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzLCB0aGVyZSBhcmUgdHdvIG92ZXJsYXlzLCB1c2VycyB3aG8gd2FudCB0byBhY2Nlc3MgdGhl IGNvbnRlbnQgc2hhcmluZyANCnNlcnZpY2Ugc2hvdWxkIGhhdmUgcmVnaXN0ZXJlZCBpbiB0aGUg YmFzaWMgb3ZlcmxheSBmaXJzdGx5LiANCk5vZGVzIG9mIHRoZSBjb250ZW50LXNoYXJpbmcgb3Zl cmxheSBjYW4gYWNjZXNzIHRoZSBiYXNpYyB1c2VyIHByb2ZpbGVzIA0Kb3ZlcmxheSB2aWEgUkVM T0FEIHByb3RvY29sLCBhbmQgYSAnb3ZlcmxheScgcGFyYW1ldGVyIGluIHRoZSBSRUxPQUQgDQpm b3J3YXJkaW5nIGhlYWQgIGNhbiBiZSB1c2VkIHRvIGRpc3Rpbmd1aXNoIGRpZmZlcmVudCBvdmVy bGF5Lg0KDQoNCg0KDQpsaWNodW4gbGkgPGxpbGljaHVuQGdtYWlsLmNvbT4gDQoyMDA5LTA3LTEz IDEwOjQxDQoNCsrVvP7Iyw0Kd2FuZy5qdW4xN0B6dGUuY29tLmNuDQqzrcvNDQpwMnBzaXBAaWV0 Zi5vcmcsIHAycHNpcC1ib3VuY2VzQGlldGYub3JnLCBzaGVuLmppb25nQHp0ZS5jb20uY24NCtb3 zOINClJlOiBbUDJQU0lQXSBOZXcgZHJhZnQgb24gY29udGVudCBzaGFyaW5nIHVzYWdlIGZvciBS RUxPQUQNCg0KDQoNCg0KDQoNCjIwMDkvNy8xMyAgPHdhbmcuanVuMTdAenRlLmNvbS5jbj46DQo+ DQo+IEhpLCBsaQ0KPiAgICBJbiB0aGlzIGRyYWZ0LCBwcm92aWRlcidzIHNlcnZlcnMgYXJlIHBy ZWZlcmFibGUgdG8gZm9ybSB0aGUgb3ZlcmxheS4NCj4gVXNlcnMgY2FuIHB1dCBzb21lIGNvbnRl bnQgaW50byB0aGlzIFJFTE9BRCBiYXNlZCBvdmVybGF5LCBidXQgYmVmb3JlIA0KdGhhdCwNCj4g dGhlIHNlY3VyaXR5IG11c3QgYmUgZ3VhcmFudGVlZC4NCj4gICAgSSB0b3RhbGx5IGFncmVlIHRo YXQgdGhlIFJFTE9BRCBiYXNlZCBvdmVybGF5IGFjdHMgYXMgbm90IG9ubHkgYSBDRE4gDQpidXQN Cj4gYWxzbyBhIGNvbnRlbnQgc3RvcmFnZSBzZXJ2ZXIuIEFzIGZvciBzdG9yaW5nIHRoZSB1c2Vy IGxpc3Qgb3IgdXNlcg0KPiBwcm9maWxlcywgSSB0aGluayAgYW4gZXhpc3Rpbmcgb3ZlcmxheSBj b3VsZCBiZSB1c2VkIHRvIGRvIHRoaXMsIGUuZy4sIA0KdGhlDQo+IGV4aXN0aW5nIHAycCBiYXNl ZCBzdWJzY3JpYmVyIGRhdGFiYXNlLg0KDQpTbyB0aGVyZSBhcmUgdHdvIG92ZXJsYXlzPyBBcmUg dGhlcmUgYW55IGludGVyYWN0aW9ucyBiZXR3ZWVuIHR3byANCm92ZXJsYXlzPw0KDQo+DQo+DQo+ ICAgIFdhbmcgSnVuKFJ1c3NlbGwgV2FuZykNCj4NCj4NCj4NCj4NCj4NCj4gbGljaHVuIGxpIDxs aWxpY2h1bkBnbWFpbC5jb20+DQo+ILeivP7IyzogIHAycHNpcC1ib3VuY2VzQGlldGYub3JnDQo+ DQo+IDIwMDktMDctMTIgMTI6MDANCj4NCj4gytW8/sjLDQo+IHNoZW4uamlvbmdAenRlLmNvbS5j bg0KPiCzrcvNDQo+IHAycHNpcEBpZXRmLm9yZw0KPiDW98ziDQo+IFJlOiBbUDJQU0lQXSBOZXcg ZHJhZnQgb24gY29udGVudCBzaGFyaW5nIHVzYWdlIGZvciBSRUxPQUQNCj4NCj4NCj4NCj4NCj4g SW50ZXJlc3RpbmcuIEkgdGhpbmsgd2UgbWF5IHN0YXJ0IGNvbnNpZGVyaW5nIHVzaW5nIFJFTE9B RCBmb3INCj4gYXBwbGljYXRpb25zIG90aGVyIHRoYW4gUDJQU0lQLiBTb21lIHF1ZXN0aW9ucyBh bmQgY29tbWVudHMgYXJlIGJlbG93Lg0KPg0KPiBJdCBzZWVtcyB0aGF0IGFsbCB0aGUgY29udGVu dHMgYXJlIHByb3ZpZGVkIGJ5IHNlcnZpY2UgcHJvdmlkZXIuIENhbg0KPiB1c2VycyB1cGxvYWQg YW5kIHNoYXJlIGNvbnRlbnRzPw0KPg0KPiBTZXJ2ZXJzIG9yIHVzZXIgUENzIGZvcm0gdGhlIHRo ZSBSRUxPQUQgb3ZlcmxheSBmb3IgY29udGVudCBzaGFyaW5nPw0KPg0KPiBJIHRoaW5rIHRoZSBS RUxPQUQgb3ZlcmxheSBpcyBtb3JlIHRoYW4gYSBDRE4uIENETiBpcyBub3QgcmVzcG9uc2libGUN Cj4gZm9yIGRhdGEgZHVyYWJpbGl0eSBidXQgdHJhZmZpYyBsb2NhbGl6YXRpb24uDQo+IERIVCBv dmVybGF5IGNhbiBhc3N1cmUgZGF0YSBkdXJhYmlsaXR5LCBhbmQgdGhpcyBkcmFmdCBhZGRzIENE Tg0KPiBmdW5jdGlvbiB0byBSRUxPQUQuDQo+IE90aGVyIHRoYW4gc3RvcmUgZmlsZXMsIHRoZSBS RUxPQUQgb3ZlcmxheSBtYXkgc3RvcmUgdXNlciBsaXN0IGZvcg0KPiB1cC1sYXllciBkaXN0cmli dXRlZCB0cmFja2VyIGZ1bmN0aW9uLg0KPg0KPiBTbyBJIHRoaW5rIHRoZSBSRUxPQUQgb3Zlcmxh eSBtYXkgaGF2ZSB0aHJlZSBmdW5jdGlvbnM6IENETiwgZmlsZQ0KPiBzdG9yaW5nIGFuZCB1c2Vy IGxpc3Qgc3RvcmluZy4NCj4gVGhlIFJFTE9BRCBvdmVybGF5IG1heSBwcm92aWRlIGFsbCB0aHJl ZSBmdW5jdGlvbnMgdG8gc29tZSBjb250ZW50cw0KPiAoZS5nLiBjb250ZW50IHByb3ZpZGVkIGJ5 IHNlcnZpY2UgcHJvdmlkZXIpDQo+IGFuZCBvbmx5IHBhcnQgZnVuY3Rpb25zIHRvIG90aGVyIGNv bnRlbnRzIChlLmcuIGNvbnRlbnRzIHByb3ZpZGVkIGJ5IA0KdXNlcnMpLg0KPg0KPg0KPg0KPiBP biBXZWQsIEp1bCAxLCAyMDA5IGF0IDk6MTYgQU0sIDxzaGVuLmppb25nQHp0ZS5jb20uY24+IHdy b3RlOg0KPj4NCj4+IEhpIGFsbCwNCj4+DQo+PiBXZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IG9u IGNvbnRlbnQgc2hhcmluZyB1c2FnZSBmb3IgUkVMT0FELiBJdCANCnByb3ZpZGVzDQo+PiB0aGUg ZnVuY3Rpb25hbGl0eSBvZiBkaXN0cmlidXRpbmcgYW5kIGZldGNoaW5nIHNoYXJlZCBjb250ZW50 IA0KZWZmaWNpZW50bHkNCj4+IHRvDQo+PiBhbmQgZnJvbSBhIFAyUCBvdmVybGF5IG5ldHdvcmss IHdoaWNoIHBlcmZvcm1zIGFzIENvbnRlbnQgRGVsaXZlcnkgDQpOZXR3b3JrDQo+PiBhbmQgaXMg c2VydmljZSBpbnNlbnNpdGl2ZS4NCj4+DQo+PiBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0DQo+ Pg0KPj4gDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zaGVuLXAy cHNpcC1jb250ZW50LXNoYXJpbmctMDAudHh0DQouDQo+PiAgQ29tbWVudHMgYXJlIHdlbGNvbWUu DQo+Pg0KPj4NCj4+IFRoYW5rcywNCj4+IEppb25nDQo+Pg0KPj4NCj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj4gWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IA0KYW5kIGFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gDQpvdGhlcnMuDQo+Pg0KPj4gVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgDQppbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgDQphZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgDQpvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2Vk IGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2UgDQpvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+ Pg0KPj4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPj4gUDJQ U0lQQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ay cHNpcA0KPj4NCj4+DQo+DQo+DQo+DQo+IC0tDQo+IFNpbmNlcmVseSB5b3VycywNCj4NCj4gTGlj aHVuIExpDQo+IE1vYmlsZSBMaWZlIE5ldyBNZWRpYSBMYWIsIEJVUFQNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUDJQU0lQIG1haWxpbmcgbGlz dA0KPiBQMlBTSVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wMnBzaXANCj4NCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGlj ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgDQppcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24gDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IA0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQo+IFRoaXMg ZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwg YW5kIA0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIA0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIA0Kb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIA0K b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KPg0KDQoN Cg0KLS0gDQpTaW5jZXJlbHkgeW91cnMsDQoNCkxpY2h1biBMaQ0KTW9iaWxlIExpZmUgTmV3IE1l ZGlhIExhYiwgQlVQVA0KDQoNCg0KAalternative002A46AB482575ENCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3Nl IG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 002A46AB482575F2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcywgdGhlcmUgYXJlIHR3byBv dmVybGF5cywgdXNlcnMgd2hvDQp3YW50IHRvIGFjY2VzcyB0aGUgY29udGVudCBzaGFyaW5nIHNl cnZpY2Ugc2hvdWxkIGhhdmUgcmVnaXN0ZXJlZCBpbiB0aGUNCmJhc2ljIG92ZXJsYXkgZmlyc3Rs eS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Ob2RlcyBvZiB0 aGUgY29udGVudC1zaGFyaW5nIG92ZXJsYXkNCmNhbiBhY2Nlc3MgdGhlIGJhc2ljIHVzZXIgcHJv ZmlsZXMgb3ZlcmxheSB2aWEgUkVMT0FEIHByb3RvY29sLCBhbmQgYSAnb3ZlcmxheScNCnBhcmFt ZXRlciBpbiB0aGUgUkVMT0FEIGZvcndhcmRpbmcgaGVhZCAmbmJzcDtjYW4gYmUgdXNlZCB0byBk aXN0aW5ndWlzaA0KZGlmZmVyZW50IG92ZXJsYXkuPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPmxpY2h1biBsaSAmbHQ7bGlsaWNodW5A Z21haWwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDA5LTA3LTEzIDEwOjQxPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPndhbmcuanVuMTdAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+cDJwc2lwQGlldGYub3JnLCBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZywNCnNoZW4uamlv bmdAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQMlBTSVBdIE5ldyBkcmFmdCBv biBjb250ZW50IHNoYXJpbmcNCnVzYWdlIGZvciBSRUxPQUQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PjIwMDkvNy8xMyAmbmJzcDsmbHQ7 d2FuZy5qdW4xN0B6dGUuY29tLmNuJmd0Ozo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSwgbGk8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDtJbiB0aGlzIGRyYWZ0LCBwcm92aWRlcidzIHNlcnZlcnMgYXJl IHByZWZlcmFibGUgdG8gZm9ybQ0KdGhlIG92ZXJsYXkuPGJyPg0KJmd0OyBVc2VycyBjYW4gcHV0 IHNvbWUgY29udGVudCBpbnRvIHRoaXMgUkVMT0FEIGJhc2VkIG92ZXJsYXksIGJ1dCBiZWZvcmUN CnRoYXQsPGJyPg0KJmd0OyB0aGUgc2VjdXJpdHkgbXVzdCBiZSBndWFyYW50ZWVkLjxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO0kgdG90YWxseSBhZ3JlZSB0aGF0IHRoZSBSRUxPQUQgYmFzZWQgb3Zl cmxheSBhY3RzIGFzDQpub3Qgb25seSBhIENETiBidXQ8YnI+DQomZ3Q7IGFsc28gYSBjb250ZW50 IHN0b3JhZ2Ugc2VydmVyLiBBcyBmb3Igc3RvcmluZyB0aGUgdXNlciBsaXN0IG9yIHVzZXI8YnI+ DQomZ3Q7IHByb2ZpbGVzLCBJIHRoaW5rICZuYnNwO2FuIGV4aXN0aW5nIG92ZXJsYXkgY291bGQg YmUgdXNlZCB0byBkbyB0aGlzLA0KZS5nLiwgdGhlPGJyPg0KJmd0OyBleGlzdGluZyBwMnAgYmFz ZWQgc3Vic2NyaWJlciBkYXRhYmFzZS48YnI+DQo8YnI+DQpTbyB0aGVyZSBhcmUgdHdvIG92ZXJs YXlzPyBBcmUgdGhlcmUgYW55IGludGVyYWN0aW9ucyBiZXR3ZWVuIHR3byBvdmVybGF5cz88YnI+ DQo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1dhbmcgSnVuKFJ1 c3NlbGwgV2FuZyk8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgbGljaHVuIGxpICZsdDtsaWxpY2h1bkBnbWFpbC5jb20mZ3Q7PGJyPg0K Jmd0OyC3orz+yMs6ICZuYnNwO3AycHNpcC1ib3VuY2VzQGlldGYub3JnPGJyPg0KJmd0Ozxicj4N CiZndDsgMjAwOS0wNy0xMiAxMjowMDxicj4NCiZndDs8YnI+DQomZ3Q7IMrVvP7Iyzxicj4NCiZn dDsgc2hlbi5qaW9uZ0B6dGUuY29tLmNuPGJyPg0KJmd0OyCzrcvNPGJyPg0KJmd0OyBwMnBzaXBA aWV0Zi5vcmc8YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7IFJlOiBbUDJQU0lQXSBOZXcgZHJhZnQg b24gY29udGVudCBzaGFyaW5nIHVzYWdlIGZvciBSRUxPQUQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbnRlcmVzdGluZy4gSSB0aGluayB3ZSBtYXkg c3RhcnQgY29uc2lkZXJpbmcgdXNpbmcgUkVMT0FEIGZvcjxicj4NCiZndDsgYXBwbGljYXRpb25z IG90aGVyIHRoYW4gUDJQU0lQLiBTb21lIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIGJlbG93 Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IHNlZW1zIHRoYXQgYWxsIHRoZSBjb250ZW50cyBhcmUg cHJvdmlkZWQgYnkgc2VydmljZSBwcm92aWRlci4gQ2FuPGJyPg0KJmd0OyB1c2VycyB1cGxvYWQg YW5kIHNoYXJlIGNvbnRlbnRzPzxicj4NCiZndDs8YnI+DQomZ3Q7IFNlcnZlcnMgb3IgdXNlciBQ Q3MgZm9ybSB0aGUgdGhlIFJFTE9BRCBvdmVybGF5IGZvciBjb250ZW50IHNoYXJpbmc/PGJyPg0K Jmd0Ozxicj4NCiZndDsgSSB0aGluayB0aGUgUkVMT0FEIG92ZXJsYXkgaXMgbW9yZSB0aGFuIGEg Q0ROLiBDRE4gaXMgbm90IHJlc3BvbnNpYmxlPGJyPg0KJmd0OyBmb3IgZGF0YSBkdXJhYmlsaXR5 IGJ1dCB0cmFmZmljIGxvY2FsaXphdGlvbi48YnI+DQomZ3Q7IERIVCBvdmVybGF5IGNhbiBhc3N1 cmUgZGF0YSBkdXJhYmlsaXR5LCBhbmQgdGhpcyBkcmFmdCBhZGRzIENETjxicj4NCiZndDsgZnVu Y3Rpb24gdG8gUkVMT0FELjxicj4NCiZndDsgT3RoZXIgdGhhbiBzdG9yZSBmaWxlcywgdGhlIFJF TE9BRCBvdmVybGF5IG1heSBzdG9yZSB1c2VyIGxpc3QgZm9yPGJyPg0KJmd0OyB1cC1sYXllciBk aXN0cmlidXRlZCB0cmFja2VyIGZ1bmN0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IFNvIEkgdGhp bmsgdGhlIFJFTE9BRCBvdmVybGF5IG1heSBoYXZlIHRocmVlIGZ1bmN0aW9uczogQ0ROLCBmaWxl PGJyPg0KJmd0OyBzdG9yaW5nIGFuZCB1c2VyIGxpc3Qgc3RvcmluZy48YnI+DQomZ3Q7IFRoZSBS RUxPQUQgb3ZlcmxheSBtYXkgcHJvdmlkZSBhbGwgdGhyZWUgZnVuY3Rpb25zIHRvIHNvbWUgY29u dGVudHM8YnI+DQomZ3Q7IChlLmcuIGNvbnRlbnQgcHJvdmlkZWQgYnkgc2VydmljZSBwcm92aWRl cik8YnI+DQomZ3Q7IGFuZCBvbmx5IHBhcnQgZnVuY3Rpb25zIHRvIG90aGVyIGNvbnRlbnRzIChl LmcuIGNvbnRlbnRzIHByb3ZpZGVkDQpieSB1c2VycykuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBPbiBXZWQsIEp1bCAxLCAyMDA5IGF0IDk6MTYgQU0sICZsdDtzaGVu Lmppb25nQHp0ZS5jb20uY24mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg SGkgYWxsLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2UgaGF2ZSBzdWJtaXR0ZWQgYSBk cmFmdCBvbiBjb250ZW50IHNoYXJpbmcgdXNhZ2UgZm9yIFJFTE9BRC4NCkl0IHByb3ZpZGVzPGJy Pg0KJmd0OyZndDsgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgZGlzdHJpYnV0aW5nIGFuZCBmZXRjaGlu ZyBzaGFyZWQgY29udGVudA0KZWZmaWNpZW50bHk8YnI+DQomZ3Q7Jmd0OyB0bzxicj4NCiZndDsm Z3Q7IGFuZCBmcm9tIGEgUDJQIG92ZXJsYXkgbmV0d29yaywgd2hpY2ggcGVyZm9ybXMgYXMgQ29u dGVudCBEZWxpdmVyeQ0KTmV0d29yazxicj4NCiZndDsmZ3Q7IGFuZCBpcyBzZXJ2aWNlIGluc2Vu c2l0aXZlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGRyYWZ0IGNhbiBiZSBmb3Vu ZCBhdDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtc2hlbi1wMnBzaXAtY29udGVudC1zaGFyaW5nLTAwLnR4dC48YnI+ DQomZ3Q7Jmd0OyAmbmJzcDtDb21tZW50cyBhcmUgd2VsY29tZS48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsmZ3Q7IEppb25nPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluDQp0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bA0KYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5DQphcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlDQpvcmlnaW5hdG9yIG9mIHRoZSBt ZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2UNCm9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoaXMg bWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRp LVNwYW0NCnN5c3RlbS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgUDJQU0lQIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IFAyUFNJUEBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08 YnI+DQomZ3Q7IFNpbmNlcmVseSB5b3Vycyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBMaWNodW4gTGk8 YnI+DQomZ3Q7IE1vYmlsZSBMaWZlIE5ldyBNZWRpYSBMYWIsIEJVUFQ8YnI+DQomZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBQMlBT SVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBQMlBTSVBAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQptYWlsIGlzIHNvbGVs eSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVu aWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxp Z2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Ns b3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQom Z3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kDQppbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUNCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yDQpv ZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRo b3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2UgaGFz IGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtDQpzeXN0 ZW0uPGJyPg0KJmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NClNpbmNlcmVseSB5 b3Vycyw8YnI+DQo8YnI+DQpMaWNodW4gTGk8YnI+DQpNb2JpbGUgTGlmZSBOZXcgTWVkaWEgTGFi LCBCVVBUPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJz cDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNw O2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRl cidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1l ZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFp biZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQm bmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNw O3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7 ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7 d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50 ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hv bSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJz cDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vy cm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNw O29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJl c3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1 c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5i c3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 002A46AB482575F2_=-- From shen.jiong@zte.com.cn Mon Jul 13 02:54:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79CCB3A6864 for ; Mon, 13 Jul 2009 02:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.835 X-Spam-Level: X-Spam-Status: No, score=-93.835 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_37=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gqqD75PPDIO for ; Mon, 13 Jul 2009 02:54:14 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 743D528C28F for ; Mon, 13 Jul 2009 02:54:04 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111642075036648; Mon, 13 Jul 2009 17:37:21 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 12012.4179221585; Mon, 13 Jul 2009 17:47:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6D9rWoi088114; Mon, 13 Jul 2009 17:53:32 +0800 (CST) (envelope-from shen.jiong@zte.com.cn) In-Reply-To: <7d6b50690907121946x69fc19a0s39a3f0ddbe56a2fe@mail.gmail.com> To: lichun li MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: shen.jiong@zte.com.cn Date: Mon, 13 Jul 2009 17:52:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-13 17:53:12, Serialize complete at 2009-07-13 17:53:12 Content-Type: multipart/alternative; boundary="=_alternative 00365AED482575F2_=" X-MAIL: mse1.zte.com.cn n6D9rWoi088114 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] New draft on content sharing usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 09:54:15 -0000 This is a multipart message in MIME format. --=_alternative 00365AED482575F2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTGljaHVuLA0KDQpTZWN0aW9uIDkgIk92ZXJsYXkgT3B0aW1pemUgRXhhbXBsZSIgaXMgYW4g ZXhhbXBsZSBvZiBvcHRpbWl6aW5nIGRhdGEgZmxvdyANCnRyYWZpYyBpZiB0aGUgb3ZlcmxheSBp cyBjb25zdHJ1Y3RlZCBhbmQgcnVubmluZyBieSBjYXJyaWVycy4gQXMgY2FycmllcnMgDQprbm93 IHRoZSB0aGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSB0b3BvbG9neSggdGhlIGJhY2tib25lIG5l dHdvcmtzIA0KaW5mcmFzdHJ1Y3R1cmUpLCB0aGV5IGNhbiBjb25zdHJ1Y3QgdGhlIG92ZXJsYXkg YnkgZG9tYWlucywgYW5kIHRoZSBkYXRhIA0KZmxvdyBpbiBvbmUgZG9tYWluIHdpbGwgbm90IGFj cm9zcyBvdmVyIGJhY2tib25lIG5ldHdvcmtzLCB0aGF0IGNhbiBsaW1pdCANCnRoZSBkYXRhIGZs b3cgYWNyb3NzIG92ZXIgYmFja2JvbmUgbmV0d29ya3MuIE5vcm1hbGx5LCB0aGUgZG9tYWlucyBh cmUgDQpjb25zdHJ1Y3RlZCBieSByZWdpb24uDQoNCkZvciB0aGUgZGV0YWlsIHVzYWdlIG9mIGNv bnRlbnQgc3RvcmluZyBieSBkb21haW4gYmFzZWQgb3ZlcmxheSwgdGhlcmUgYXJlIA0KbWFueSBt ZXRob2RzLiANCkZvciBpbnN0YW5jZSwgdGhlIGNvbnRlbnQgcHJvdmlkZXIgY2FuIGRpc3RyaWJ1 dGUgdGhlIGNvbnRlbnQgdG8gZWFjaCANCmRvbWFpbiBvZiB0aGUgb3ZlcmxheSwgdGhlIHJlc291 cmNlIElEIGlzIGdlbmVyYXRlZCBieSBkb21haW4gSUQoQ2FuIGJlIA0KaWRlbnRpZmllZCBieSBj YXJyaWVycyBvciBNYXkgaGFzaCBieSBkb21haW4gbmFtZSkgcGx1cyBnZW5lcmljIElEKCBlLmcu IA0KaGFzaGVkIGJ5IHJlc291cmNlIG5hbWUpLiBIZXJlLCB0aGUgZG9tYWluIElEIGlzIHRoZSBp ZGVudGl0eSBvZiBvbmUgDQpkb21haW4sIGFuZCBhbGwgdGhlIG5vZGUgSURzIGFuZCByZXNvdXJj ZSBJRHMgaW4gb25lIGRvbWFpbiBhcmUgZ2VuZXJhdGVkIA0KYnkgZG9tYWluIElEIHBsdXMgSURz IGNvbnN0aXR1dGVkIGJ5IHRoZSBzcGVjaWZpYyBydWxlIGFuZCBoYXNoIGFsZ29yaXRobSANCi4g V2hlbiBvbmUgQ1NDKENvbnRlbnQgU2hhcmluZyBDbGllbnQpIHdhbnRzIHRvIGZldGNoIHJlc291 cmNlLCBpdCANCmdlbmVyYXRlcyB0aGUgcmVzb3VyY2UgSUQgYnkgc2FtZSBydWxlIHN1Y2ggYXMg ZG9tYWluIElEIHBsdXMgSUQoZS5nLiANCmhhc2hlZCBieSByZXNvdXJjZSBuYW1lKSBhbmQgZ2V0 cyB0aGUgcmVzb3VyY2UgZnJvbSB0aGUgcGVlciBpbiBzYW1lIA0KZG9tYWluLiANCg0KVGhhbmtz Lg0KSmlvbmcNCiAgDQoNCg0KDQoNCg0KbGljaHVuIGxpIDxsaWxpY2h1bkBnbWFpbC5jb20+IA0K MjAwOS0wNy0xMyAxMDo0Ng0KDQrK1bz+yMsNCnNoZW4uamlvbmdAenRlLmNvbS5jbg0Ks63LzQ0K cDJwc2lwQGlldGYub3JnDQrW98ziDQpSZTogW1AyUFNJUF0gTmV3IGRyYWZ0IG9uIGNvbnRlbnQg c2hhcmluZyB1c2FnZSBmb3IgUkVMT0FEDQoNCg0KDQoNCg0KDQpTZWN0aW9uIDkgIk92ZXJsYXkg T3B0aW1pemUgRXhhbXBsZSIgaXMgaW50ZXJlc3RpbmcuIENhbiB5b3UgZ2l2ZSBtb3JlDQpkZXRh aWxzIGFib3V0IHRoZSBtdWx0aS1kb21haW4gb3ZlcmxheSBhcmNoaXRlY3R1cmU/IEZvciBleGFt cGxlLA0Kd2hpY2ggY29udGVudCBpcyBzdG9yZWQgaW4gd2hpY2ggZG9tYWluPw0KDQpPbiBXZWQs IEp1bCAxLCAyMDA5IGF0IDk6MTYgQU0sIDxzaGVuLmppb25nQHp0ZS5jb20uY24+IHdyb3RlOg0K Pg0KPiBIaSBhbGwsDQo+DQo+IFdlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgb24gY29udGVudCBz aGFyaW5nIHVzYWdlIGZvciBSRUxPQUQuIEl0IA0KcHJvdmlkZXMNCj4gdGhlIGZ1bmN0aW9uYWxp dHkgb2YgZGlzdHJpYnV0aW5nIGFuZCBmZXRjaGluZyBzaGFyZWQgY29udGVudCANCmVmZmljaWVu dGx5IHRvDQo+IGFuZCBmcm9tIGEgUDJQIG92ZXJsYXkgbmV0d29yaywgd2hpY2ggcGVyZm9ybXMg YXMgQ29udGVudCBEZWxpdmVyeSANCk5ldHdvcmsNCj4gYW5kIGlzIHNlcnZpY2UgaW5zZW5zaXRp dmUuDQo+DQo+IFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQNCj4gDQpodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zaGVuLXAycHNpcC1jb250ZW50LXNoYXJpbmctMDAu dHh0DQouDQo+ICBDb21tZW50cyBhcmUgd2VsY29tZS4NCj4NCj4NCj4gVGhhbmtzLA0KPiBKaW9u Zw0KPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUg c2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRl bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz ZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NCj4gDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBh cmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHBy ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIu DQo+IA0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4gUDJQU0lQQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQo+ DQo+DQoNCg0KDQotLSANClNpbmNlcmVseSB5b3VycywNCg0KTGljaHVuIExpDQpNb2JpbGUgTGlm ZSBOZXcgTWVkaWEgTGFiLCBCVVBUDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVs eSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVu aWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGln YXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9z ZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1h aWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5k IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4g QW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRp dmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2Vz IGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 00365AED482575F2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SGkgTGljaHVuLDwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5TZWN0aW9u IDkgJnF1b3Q7T3ZlcmxheSBPcHRpbWl6ZQ0KRXhhbXBsZSZxdW90OyBpcyBhbiBleGFtcGxlIG9m IG9wdGltaXppbmcgZGF0YSBmbG93IHRyYWZpYyBpZiB0aGUgb3ZlcmxheQ0KaXMgY29uc3RydWN0 ZWQgYW5kIHJ1bm5pbmcgYnkgY2FycmllcnMuIEFzIGNhcnJpZXJzIGtub3cgdGhlIHRoZSBuZXR3 b3JrDQppbmZyYXN0cnVjdHVyZSB0b3BvbG9neSggdGhlIGJhY2tib25lIG5ldHdvcmtzIGluZnJh c3RydWN0dXJlKSwgdGhleSBjYW4NCmNvbnN0cnVjdCB0aGUgb3ZlcmxheSBieSBkb21haW5zLCBh bmQgdGhlIGRhdGEgZmxvdyBpbiBvbmUgZG9tYWluIHdpbGwNCm5vdCBhY3Jvc3Mgb3ZlciBiYWNr Ym9uZSBuZXR3b3JrcywgdGhhdCBjYW4gbGltaXQgdGhlIGRhdGEgZmxvdyBhY3Jvc3MNCm92ZXIg YmFja2JvbmUgbmV0d29ya3MuIE5vcm1hbGx5LCB0aGUgZG9tYWlucyBhcmUgY29uc3RydWN0ZWQg YnkgcmVnaW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj5Gb3IgdGhlIGRldGFpbCB1c2FnZSBvZiBjb250ZW50DQpzdG9yaW5nIGJ5IGRvbWFp biBiYXNlZCBvdmVybGF5LCB0aGVyZSBhcmUgbWFueSBtZXRob2RzLiA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Rm9yIGluc3RhbmNlLCB0aGUgY29udGVu dCBwcm92aWRlcg0KY2FuIGRpc3RyaWJ1dGUgdGhlIGNvbnRlbnQgdG8gZWFjaCBkb21haW4gb2Yg dGhlIG92ZXJsYXksIHRoZSByZXNvdXJjZQ0KSUQgaXMgZ2VuZXJhdGVkIGJ5IGRvbWFpbiBJRChD YW4gYmUgaWRlbnRpZmllZCBieSBjYXJyaWVycyBvciBNYXkgaGFzaA0KYnkgZG9tYWluIG5hbWUp IHBsdXMgZ2VuZXJpYyBJRCggZS5nLiBoYXNoZWQgYnkgcmVzb3VyY2UgbmFtZSkuIEhlcmUsIHRo ZQ0KZG9tYWluIElEIGlzIHRoZSBpZGVudGl0eSBvZiBvbmUgZG9tYWluLCBhbmQgYWxsIHRoZSBu b2RlIElEcyBhbmQgcmVzb3VyY2UNCklEcyBpbiBvbmUgZG9tYWluIGFyZSBnZW5lcmF0ZWQgYnkg ZG9tYWluIElEIHBsdXMgSURzIGNvbnN0aXR1dGVkIGJ5IHRoZQ0Kc3BlY2lmaWMgcnVsZSBhbmQg aGFzaCBhbGdvcml0aG0gLiBXaGVuIG9uZSBDU0MoQ29udGVudCBTaGFyaW5nIENsaWVudCkNCndh bnRzIHRvIGZldGNoIHJlc291cmNlLCBpdCBnZW5lcmF0ZXMgdGhlIHJlc291cmNlIElEIGJ5IHNh bWUgcnVsZSBzdWNoDQphcyBkb21haW4gSUQgcGx1cyBJRChlLmcuIGhhc2hlZCBieSByZXNvdXJj ZSBuYW1lKSBhbmQgZ2V0cyB0aGUgcmVzb3VyY2UNCmZyb20gdGhlIHBlZXIgaW4gc2FtZSBkb21h aW4uIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij5UaGFua3MuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i Pkppb25nPC9mb250Pg0KPGJyPjx0dD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250PjwvdHQ+PGZv bnQgc2l6ZT0zIGNvbG9yPSMzMzY2OTk+IDwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5saWNodW4gbGkgJmx0O2xpbGljaHVu QGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAwOS0wNy0xMyAxMDo0NjwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5zaGVuLmppb25nQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPnAycHNpcEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQMlBTSVBdIE5l dyBkcmFmdCBvbiBjb250ZW50IHNoYXJpbmcNCnVzYWdlIGZvciBSRUxPQUQ8L2ZvbnQ+PC90YWJs ZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8 YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlNlY3Rpb24gOSAm cXVvdDtPdmVybGF5IE9wdGltaXplIEV4YW1wbGUmcXVvdDsgaXMNCmludGVyZXN0aW5nLiBDYW4g eW91IGdpdmUgbW9yZTxicj4NCmRldGFpbHMgYWJvdXQgdGhlIG11bHRpLWRvbWFpbiBvdmVybGF5 IGFyY2hpdGVjdHVyZT8gRm9yIGV4YW1wbGUsPGJyPg0Kd2hpY2ggY29udGVudCBpcyBzdG9yZWQg aW4gd2hpY2ggZG9tYWluPzxicj4NCjxicj4NCk9uIFdlZCwgSnVsIDEsIDIwMDkgYXQgOToxNiBB TSwgJmx0O3NoZW4uamlvbmdAenRlLmNvbS5jbiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZn dDsgSGkgYWxsLDxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQg b24gY29udGVudCBzaGFyaW5nIHVzYWdlIGZvciBSRUxPQUQuIEl0DQpwcm92aWRlczxicj4NCiZn dDsgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgZGlzdHJpYnV0aW5nIGFuZCBmZXRjaGluZyBzaGFyZWQg Y29udGVudCBlZmZpY2llbnRseQ0KdG88YnI+DQomZ3Q7IGFuZCBmcm9tIGEgUDJQIG92ZXJsYXkg bmV0d29yaywgd2hpY2ggcGVyZm9ybXMgYXMgQ29udGVudCBEZWxpdmVyeQ0KTmV0d29yazxicj4N CiZndDsgYW5kIGlzIHNlcnZpY2UgaW5zZW5zaXRpdmUuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhl IGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDxicj4NCiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtc2hlbi1wMnBzaXAtY29udGVudC1zaGFyaW5nLTAwLnR4dC48YnI+ DQomZ3Q7ICZuYnNwO0NvbW1lbnRzIGFyZSB3ZWxjb21lLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0OyBKaW9uZzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCiZndDsgWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05v dGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5i c3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5i c3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJz cDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRl ZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5i c3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNw O2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5i c3A7b3RoZXJzLjxicj4NCiZndDsgVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5i c3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNw O2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9y Jm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7 YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7 dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlm eSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2Uu Jm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtzZW5kZXIuPGJyPg0KJmd0OyBUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZu YnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNw O1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS48YnI+DQom Z3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgUDJQU0lQIG1haWxpbmcgbGlzdDxicj4NCiZndDsgUDJQU0lQQGlldGYu b3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNp cDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KU2lu Y2VyZWx5IHlvdXJzLDxicj4NCjxicj4NCkxpY2h1biBMaTxicj4NCk1vYmlsZSBMaWZlIE5ldyBN ZWRpYSBMYWIsIEJVUFQ8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhl Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt YWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZu YnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNw O21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Bl cm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNw O29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRo aXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0 ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQm bmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8m bmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNw O3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2lu Jm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5h dG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5i c3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNw O3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhp cyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZu YnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRp LVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00365AED482575F2_=-- From ligangyf@chinamobile.com Mon Jul 13 02:59:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053FD3A6904 for ; Mon, 13 Jul 2009 02:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.398 X-Spam-Level: **** X-Spam-Status: No, score=4.398 tagged_above=-999 required=5 tests=[AWL=-2.360, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, J_CHICKENPOX_62=0.6, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzfgxuPOx-dc for ; Mon, 13 Jul 2009 02:59:14 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id 7CFA93A6949 for ; Mon, 13 Jul 2009 02:58:52 -0700 (PDT) Received: from frank ([10.2.2.108]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2009071317590851-16406 ; Mon, 13 Jul 2009 17:59:08 +0800 From: "Li Gang" To: References: Date: Mon, 13 Jul 2009 10:59:12 +0100 Message-ID: <82D4F295D9E24C5AA6934CFF0973329D@frank> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcoDhX066dIj6gcKQZqj0n9jNx0tCQAGC3XA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-07-13 17:59:08, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2009-07-13 17:59:23, Serialize complete at 2009-07-13 17:59:23 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0161_01CA03A8.F44852D0" Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Traffic localization for RELOAD - for comments X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 09:59:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0161_01CA03A8.F44852D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="gb2312" Hi, Gao, =20 Thanks for your comments and indeed localization is really critical for = the feasibility of P2PSIP network especially for operators with a big number = of subscribers across a widespread geographical areas.=20 =20 As for your comments, please see my reply below: I agree we made the mistake by putting the section =A1=B0proposal=A1=B1 = at the wrong place and will correct it in the next version. And also we will consider your suggestions to split it into 2 drafts.=20 =20 Also I agree that *Location-based Node ID* is one of possible ways to achieve localization and it I will consider adding some papers for = further explanation. =20 Li Gang _____ =20 From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: Monday, July 13, 2009 2:44 PM To: Li Gang Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Traffic localization for RELOAD - for comments =20 Hi,=20 First, I am really glad to see a draft on the topic of *Locality* for RELOAD. In fact, considering localization is important for network = operator while using p2p way.=20 There are some comments/doubts:=20 1. Why put 3.3(proposal) in the *Requirements* chapter?=20 And if you want giving the final solution in the same draft, I think = that the 3.3(proposal) need enriched to be convincing. Further, I think split = the one into two or more drafts may be better. The first one can concentrate = on the *Requirements* and *Metrics/Measurement*. And separated drafts(in = fact, the solution can be more than one) for proposed DHTs considering localization. Especially important thing is the *Metrics/Measurement* = which is the estimator for the proposed DHTs.=20 2. It is better to add some early paper as reference.=20 As the solution in 3.3(proposal) use the well-known way of = *Location-based Node ID*, it is better to add some early paper(which introducing such = way) as reference.=20 BTW, Because *localization* is very important for QoS and operation, I really want to see the WG making *localization* as a research direction = for P2PSIP.=20 Thanks.=20 Gao=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 "Li Gang" =20 =B7=A2=BC=FE=C8=CB: p2psip-bounces@ietf.org=20 2009-07-13 09:47=20 =CA=D5=BC=FE=C8=CB =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 [P2PSIP] Traffic localization for RELOAD - for comments =20 =20 =20 =20 Hi, all,=20 =20 I submitted a draft about traffic localization for RELOAD, and the = abstract is as follows:=20 Hope you can take a few minutes to look at it and let me know your = comments :-)=20 =20 Abstract:=20 This document describes the traffic problems due to randomly distributed data storage in P2PSIP overlay, identifies the traffic localization requirements, and then proposes an overlay construction and data storage mechanism to implement traffic localization for REsource LOcation And Discovery (RELOAD). Specifically, it's proposed to add location = indicator to the Peer node ID, for example, the beginning 5 bit hash ID stands for = the peer location, and user data with the location indication shall be = possible to be stored in local peer, thus to achieve traffic localization, reduce backbone network traffic, and improve the efficiency and QoS of the = whole network.=20 =20 You can refer to the following link for more details:=20 http://tools.ietf.org/html/draft-li-p2psip-localization-00=20 =20 Really appreciate your comments and feedback,=20 =20 Li Gang=20 China Mobile=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip =20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------=_NextPart_000_0161_01CA03A8.F44852D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

Hi, = Gao,

 =

Thanks for your = comments and indeed localization is really critical for the feasibility of P2PSIP = network especially for operators with a big number of subscribers across a widespread = geographical areas.

 =

As for your = comments, please see my reply below:

I agree we made = the mistake by putting the section =A1=B0proposal=A1=B1 at the wrong place = and will correct it in the next version.

And also we will = consider your suggestions to split it into 2 drafts. =

 =

Also I agree = that *Location-based Node ID* is one of possible ways to achieve localization and it I will = consider adding some papers for further explanation.

 =

Li = Gang

From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Monday, July 13, = 2009 2:44 PM
To: Li Gang
Cc: p2psip@ietf.org
Subject: Re: [P2PSIP] = Traffic localization for RELOAD - for comments

 


Hi,

First, I am really glad to see a draft on the = topic of *Locality* for RELOAD. In fact, considering localization is important = for network operator while using p2p way. =

There are some = comments/doubts:

1. Why put 3.3(proposal) in the *Requirements* = chapter?
And if you want giving the final solution in the = same draft, I think that the 3.3(proposal) need enriched to be convincing. = Further, I think split the one into two or more drafts may be better. The first = one can concentrate on the *Requirements* and *Metrics/Measurement*. And = separated drafts(in fact, the solution can be more than one) for proposed DHTs = considering localization. Especially important thing is the *Metrics/Measurement* = which is the estimator for the proposed DHTs. =

2. It is better to add some early paper as = reference.
As the solution in 3.3(proposal) use the = well-known way of *Location-based Node ID*, it is better to add some early paper(which introducing such way) as reference. =


BTW, Because *localization* is very important = for QoS and operation, I really want to see the WG making *localization* as a = research direction for P2PSIP.

Thanks.

Gao
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

"L= i Gang" <ligangyf@chinamobile.com>
=B7=A2=BC=FE=C8=CB:  p2psip-bounces@ietf.org

2009-07-13 09:47

=CA=D5=BC=FE=C8=CB

<p2psip@ietf.org><= /span>

=B3=AD=CB=CD

 

=D6=F7=CC=E2

[P2PSIP] Traffic localization for RELOAD - for comments

 

 

 

 


Hi, all,
 
I submitted a draft about traffic localization for = RELOAD, and the abstract is as follows:
Hope you can take a few minutes to look at it and let = me know your comments J
 
Abstract:
This document describes the traffic problems due to = randomly distributed data storage in P2PSIP overlay, identifies the traffic = localization requirements, and then proposes an overlay construction and data storage mechanism to implement traffic localization for REsource LOcation And = Discovery (RELOAD). Specifically, it's proposed to add location indicator to the = Peer node ID, for example, the beginning 5 bit hash ID stands for the peer = location, and user data with the location indication shall be possible to be = stored in local peer, thus to achieve traffic localization, reduce backbone = network traffic, and improve the efficiency and QoS of the whole = network.
 
You can refer to the following link for more = details:
http://tools.ietf.org/html/d= raft-li-p2psip-localization-00
 
Really appreciate your comments and = feedback,
 
Li Gang
China Mobile
 _______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

 

 
----------------------------------------------=
----------
ZTE Information Security Notice=
: The information contained in this mail&nb=
sp;is solely property of the sender's organ=
ization. This mail communication is confidential=
. Recipients named above are obligated to&n=
bsp;maintain secrecy and are not permitted =
to disclose the contents of this communicat=
ion to others.
This email and any files&n=
bsp;transmitted with it are confidential and&nbs=
p;intended solely for the use of the i=
ndividual or entity to whom they are a=
ddressed. If you have received this email&n=
bsp;in error please notify the originator o=
f the message. Any views expressed in =
this message are those of the individual&nb=
sp;sender.
This message has been scan=
ned for viruses and Spam by ZTE Anti-S=
pam system.
------=_NextPart_000_0161_01CA03A8.F44852D0-- From dyork@voxeo.com Mon Jul 13 06:53:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2175728C2DB for ; Mon, 13 Jul 2009 06:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1bQp8yAs2tr for ; Mon, 13 Jul 2009 06:53:26 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 8260D28C126 for ; Mon, 13 Jul 2009 06:53:25 -0700 (PDT) Received: from [66.65.229.48] (account dyork HELO pc-00148.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 49334769; Mon, 13 Jul 2009 13:53:40 +0000 Message-Id: From: Dan York To: Roni Even In-Reply-To: <082701ca0387$5057a570$f106f050$%roni@huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-136-750562919 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Jul 2009 09:53:38 -0400 References: <082701ca0387$5057a570$f106f050$%roni@huawei.com> X-Mailer: Apple Mail (2.930.3) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] New version for draft-matuszewski-p2psip-security-requirements-05 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 13:53:27 -0000 --Apple-Mail-136-750562919 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Folks, I just wanted to make two points about this new draft: 1. We on the author team failed to include one major acknowledgement in this revision - we really must thank Roni Even for all of his work in providing comments on the previous draft and also perhaps more importantly for his help in encouraging some of the email communication and conference calls we had. We will definitely include acknowledgement of this in the next draft. 2. This revision also includes for the first time a section I wrote about security concerns related to interconnection of P2PSIP systems to the PSTN and to external SIP systems. The reality is that many if not most P2PSIP systems will want to connect to the larger SIP infrastructure as well as the traditional PSTN. Given this is a security overview, I felt it important to raise these issues for someone considering P2PSIP systems to consider. As it is new text, I'd certainly welcome any comments and feedback. Thanks, Dan On Jul 13, 2009, at 2:58 AM, Roni Even wrote: > Hi, > There is a new draft on security for p2psip titled p2psip security > overview and risk analysis in http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements-05 > > The document is similar to the previous version but based on the > discussion in the previous meeting all the requirements were taken > out and sent to the mailing list (sees thread discussion on security > requirements). > This document provides a security overview and analysis for the > Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. > It discusses security threats for the P2PSIP architecture and its > components. It compares security difference between client/server > (C/S) and P2P implementations of SIP, and then partitions the > P2PSIP architecture into layers and analyzes the security issues in > each layer and the security relationship among the layers. > Thanks > Roni Even > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo --Apple-Mail-136-750562919 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Folks,

I = just wanted to make two points about this new = draft:

1. We on the author team failed to = include one major acknowledgement in this revision - we really must = thank Roni Even for all of his work in providing comments on the = previous draft  and also perhaps more importantly for his help in = encouraging some of the email communication and conference calls we had. = We will definitely include acknowledgement of this in the next = draft.

2. This revision also includes for the = first time a section I wrote about security concerns related to = interconnection of P2PSIP systems to the PSTN and to external SIP = systems.  The reality is that many if not most P2PSIP systems will = want to connect to the larger SIP infrastructure as well as the = traditional PSTN. Given this is a security overview, I felt it important = to raise these issues for someone considering P2PSIP systems to = consider.  As it is new text, I'd certainly welcome any comments = and = feedback.

Thanks,
Dan

On Jul 13, 2009, at 2:58 AM, Roni Even wrote:

Hi,
There is a new draft on security for p2psip titled p2psip = security overview and risk analysis in  
________________________________________= _______
P2PSIP mailing list


= --Apple-Mail-136-750562919-- From ekr@rtfm.com Mon Jul 13 07:36:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C6B3A6A8A; Mon, 13 Jul 2009 07:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb1aFUcvwJNM; Mon, 13 Jul 2009 07:36:46 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id 59DCC3A6A97; Mon, 13 Jul 2009 07:36:46 -0700 (PDT) Received: by yxe34 with SMTP id 34so1968784yxe.29 for ; Mon, 13 Jul 2009 07:37:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.97.18 with SMTP id u18mr2261815agb.96.1247495834727; Mon, 13 Jul 2009 07:37:14 -0700 (PDT) In-Reply-To: <026001ca0385$927b2c80$0f0ca40a@china.huawei.com> References: <026001ca0385$927b2c80$0f0ca40a@china.huawei.com> Date: Mon, 13 Jul 2009 07:37:14 -0700 Message-ID: From: Eric Rescorla To: Song Haibin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: p2psip-bounces@ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 14:36:47 -0000 On Sun, Jul 12, 2009 at 11:45 PM, Song Haibin wrote: > Bruce, > > I followed this thread and generally I like this option. It would be > explicitly useful to identify client and peer operations. I'm a little > confused why we should depend on the Update message to determine whether an > attached node is a client or a peer. This is a category error: we don't depend on the Update message to determine whether an attached node is a client or peer because client isn't an important concept in RELOAD. Rather, the rules cause peers to treat adjacencies correctly whether they are peers, clients, or peers who haven't completed the join process yet. There is no need for a peer to detect or remember whether an adjacency is a client or peer. -Ekr From hardie@qualcomm.com Mon Jul 13 11:47:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31BE3A6A0C; Mon, 13 Jul 2009 11:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.766 X-Spam-Level: X-Spam-Status: No, score=-103.766 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6dmYjCElffN; Mon, 13 Jul 2009 11:47:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 6C8223A685F; Mon, 13 Jul 2009 11:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1247510849; x=1279046849; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20=0D =0A=20<026001ca0385$927b2c80$0f0ca40a@china.huawei.com> =0D=0A=20|Date:=20Mon,=2013=20Jul=202009=2011:47:26=20 -0700|To:=20Eric=20Rescorla=20,=20Song=20Ha ibin=20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[P2PSIP]=20Client=20o peration=20in=20RELOAD|CC:=20"p2psip-bounces@ietf.org"=20 ,=0D=0A=20=20=20=20=20=20=20=20" p2psip@ietf.org"=0D=0A=09|Content-Type: =20text/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20 E=3DMcAfee=3Bi=3D"5300,2777,5675"=3B=20a=3D"20656772"; bh=sgPzriRvBWKxo4RWx43dUubr3o7qcJwZdFq86w+n7Kg=; b=faK2DxyOcunRf/Z20e4U7gSk20CNpTiISXmODrr1pX/+9+rGabmVVD54 8f6WOcLUAFUSmm9Jot3CL5HflVVevdXdI6xS0I4hgzj5diuic1OUHrc/4 oNQdZkSwhaw5+uCopGjQ8vCtC2KJeYCnOTtrW/gpdU+fV67Bag+o3j34m o=; X-IronPort-AV: E=McAfee;i="5300,2777,5675"; a="20656772" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2009 11:47:29 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6DIlS3d007756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jul 2009 11:47:28 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6DIlS9R001010 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Jul 2009 11:47:28 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 13 Jul 2009 11:47:28 -0700 Received: from [24.4.237.86] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 13 Jul 2009 11:47:27 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <026001ca0385$927b2c80$0f0ca40a@china.huawei.com> Date: Mon, 13 Jul 2009 11:47:26 -0700 To: Eric Rescorla , Song Haibin From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "p2psip-bounces@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 18:47:02 -0000 At 7:37 AM -0700 7/13/09, Eric Rescorla wrote: > >This is a category error: we don't depend on the Update message to determine >whether an attached node is a client or peer because client isn't >an important concept in RELOAD. Rather, the rules cause peers to treat >adjacencies >correctly whether they are peers, clients, or peers who haven't >completed the join >process yet. There is no need for a peer to detect or remember whether an >adjacency is a client or peer. > >-Ekr Speaking personally, I think there is a fair chance that a peer might want to treat an adjacent node differently if it is a client and if it is a peer that intends to but hasn't completed the join process yet. I understand the "a stranger is a friend you haven't met" theory behind the current approach which makes them equivalent. But that understanding is based largely on the explanation given on the list. I think that some small promotion in the concept of client from our current stance would be useful. We already know that people will do this, and having explicit text on how strikes me as a good idea. As I said before I'd be okay with just text in the document that expounded the current theory. That would help later readers better understand why long-term adjacencies without complete join processes shouldn't be treated as errors. My personal style preference would be for a more explicit set of distinguishing characteristics, but I recognize that may be largely a style thing. regards, Ted From ekr@rtfm.com Mon Jul 13 11:56:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFBF3A67AF; Mon, 13 Jul 2009 11:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUKNU0VBYboh; Mon, 13 Jul 2009 11:56:21 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 763EB3A69E9; Mon, 13 Jul 2009 11:56:21 -0700 (PDT) Received: by pzk36 with SMTP id 36so2842618pzk.29 for ; Mon, 13 Jul 2009 11:56:50 -0700 (PDT) Received: by 10.140.139.6 with SMTP id m6mr2844633rvd.144.1247511410337; Mon, 13 Jul 2009 11:56:50 -0700 (PDT) Received: from ?10.22.14.2? ([166.205.131.2]) by mx.google.com with ESMTPS id g31sm1583123rvb.50.2009.07.13.11.56.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Jul 2009 11:56:49 -0700 (PDT) References: <026001ca0385$927b2c80$0f0ca40a@china.huawei.com> Message-Id: <1C897BFD-3620-489E-ABCA-2ECE953868D3@rtfm.com> From: Eric Rescorla To: Ted Hardie In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Date: Mon, 13 Jul 2009 11:56:18 -0700 Cc: "p2psip-bounces@ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] Client operation in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 18:56:22 -0000 On Jul 13, 2009, at 11:47 AM, Ted Hardie wrote: > At 7:37 AM -0700 7/13/09, Eric Rescorla wrote: >> >> This is a category error: we don't depend on the Update message to >> determine >> whether an attached node is a client or peer because client isn't >> an important concept in RELOAD. Rather, the rules cause peers to >> treat >> adjacencies >> correctly whether they are peers, clients, or peers who haven't >> completed the join >> process yet. There is no need for a peer to detect or remember >> whether an >> adjacency is a client or peer. >> >> -Ekr > > Speaking personally, I think there is a fair chance that a peer > might want > to treat an adjacent node differently if it is a client and if it is > a peer that intends > to but hasn't completed the join process yet. I understand the > "a stranger is a friend you haven't met" theory behind the current > approach > which makes them equivalent. But that understanding is based > largely on > the explanation given on the list. I think that some small > promotion in > the concept of client from our current stance would be useful. > We already know that people will do this, and having explicit text > on how > strikes me as a good idea. > > As I said before I'd be okay with just text in the document that > expounded the current theory. That would help later readers better > understand > why long-term adjacencies without complete join processes shouldn't be > treated as errors. My personal style preference would be for a more > explicit set of distinguishing characteristics, but I recognize that > may be > largely a style thing. > I have added additional explanatory material in the forthcoming draft Ekr From root@core3.amsl.com Mon Jul 13 17:00:01 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D94FA28C458; Mon, 13 Jul 2009 17:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090714000001.D94FA28C458@core3.amsl.com> Date: Mon, 13 Jul 2009 17:00:01 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 00:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : C. Jennings, et al. Filename : draft-ietf-p2psip-base-03.txt Pages : 146 Date : 2009-07-13 In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC 3979 respectively. They refer only to those RFCs and not any documents that update or supersede them. This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-base-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13165302.I-D@ietf.org> --NextPart-- From dwcraig@qualcomm.com Tue Jul 14 17:14:54 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961873A6881 for ; Tue, 14 Jul 2009 17:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6jvfZLG9RO7 for ; Tue, 14 Jul 2009 17:14:53 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E949E3A67FA for ; Tue, 14 Jul 2009 17:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=dwcraig@qualcomm.com; q=dns/txt; s=qcdkim; t=1247616925; x=1279152925; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Craig,=20Dave"=20|To:=20" p2psip@ietf.org"=20|Date:=20Tue,=2014=20 Jul=202009=2017:13:24=20-0700|Subject:=20RE:=20[P2PSIP] =20I-D=20Action:draft-ietf-p2psip-base-03.txt |Thread-Topic:=20[P2PSIP]=20I-D=20Action:draft-ietf-p2psi p-base-03.txt|Thread-Index:=20AcoEFxyo3JTzbVIkQwSXjBQ6mv3 wnQAod0UQ|Message-ID:=20|References:=20<20 090714000001.D94FA28C458@core3.amsl.com>|In-Reply-To:=20< 20090714000001.D94FA28C458@core3.amsl.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5676"=3B=20a=3D"20713071"; bh=uuFb1Y2iBMgO0uoPF0/64vX9MxscNiQyYDeLOfWZFJk=; b=iIH5kIwPlnK49qL29wvrw4X4upyWk1TLHgQ0iz9s10cB889PDs0jNBHM ju3WN96vBd6xHP/ZcsZJIM+kPQVMAgkqdtUGVRLAUaT9sGntyZ7eqSlSL yS3hcW954lK+wMjyUKwmB1SmgWkoRWlPaAv1QFP7t4aeqcGIIPMf70enf g=; X-IronPort-AV: E=McAfee;i="5300,2777,5676"; a="20713071" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2009 17:13:27 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6F0DRwd011036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Jul 2009 17:13:27 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6F0DQfe021391 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 14 Jul 2009 17:13:26 -0700 (PDT) Received: from NASANEXMB03.na.qualcomm.com ([10.45.76.130]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Tue, 14 Jul 2009 17:13:26 -0700 From: "Craig, Dave" To: "p2psip@ietf.org" Date: Tue, 14 Jul 2009 17:13:24 -0700 Thread-Topic: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt Thread-Index: AcoEFxyo3JTzbVIkQwSXjBQ6mv3wnQAod0UQ Message-ID: References: <20090714000001.D94FA28C458@core3.amsl.com> In-Reply-To: <20090714000001.D94FA28C458@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 00:14:54 -0000 I had a few questions on my interpretation of the latest updates as well a = few typos. 1. I was trying to understand the change made in 3.2.1. Could that change = also be read as follows? Note that clients that chose this option MUST process Update messages from = the peer. Those updates can indicate that the peer no longer owns the Clie= nt's Node-ID. The client then forms a connection to the appropriate peer. 2. The change made at the end of 5.4.1. All overlay algorithms MUST specify maintenance procedures _that_ send Upda= tes to all members of the Connection Table... 3. The change made at the beginning on 5.4.2.3 seems to conflict with that = at the end of 5.4.1. If you MUST send Updates to all members of the connec= tion table, then why is it a SHOULD in 5.4.2.3? 4. Should the IceExtension in 5.5.1.1 be a TLV, so stacks not comprehending= the extensions can still Attach? That preserves a little more of the exte= nsibility in the SDP string encoding. 5. In 5.5.2.3, first paragraph, would this read a little easier as, "... Wh= en a connection forms, the node MUST check _that_ the certificate is for th= e node that _sent_ AttachLiteReqAns..." 6. In 5.5.3., first paragraph, "The AppAttach request and its response cont= ain _an_ application attribute..." 7. In 5.6.2.2., end of paragraph, it looks like a dangling sentence was not= finished being removed. 8. In 5.6.2.2.1. third paragraph, "...looking at the time the ACK was recei= ved and the time when the message was sent." 9. In 5.6.2.2.1. fifth paragraph, was the following intended? "If all retr= ansmissions for a message fail, _the sending node should close the connecti= on routing the message_." Should there also be additional hysteresis to ma= ke sure that a failing connection is not quickly reestablished under a fast= chord-reload-ping-frequency? 10. In 5.6.3, second paragraph, "take into account space to allow the via a= nd _destination_ lists to grow." 11. In 10.1, your -frequency elements actually specify periods not occurren= ces per unit of time. Suggest renaming these to end in "-period" or "-inte= rval". End users or developers may enter in the wrong value here if they g= o by the label name alone. 12. In 10.1, I found descriptions for the namespace and encoding requiremen= ts for the overlay configuration document. Is it ok to leave it implicit t= hat these apply to the kind configuration documents sent in 5.5.6.1? 13. In 10.1, "root-cert This element contains PEM encoded X.509v3 certifi= cates that are a..." 14. In 10.1, Could the following: kinds-signature This signature is computed across the prevision kind from the beginning of the first < of the kind to the end of the last > of the kind in the same was as the "signature element described later in this section. be reworded as? kind-signature This signature is computed across the kind from the beginning of the first < of the kind to the end of the last > of the kind in the same way as the "signature element described later in this section. Likewise, kinds-signer in the descriptions appears to be kind-signer in the= example. Suggest updating example with kinds-signer. 15. In 10.5 there's a reference to a broadcast-peers element in the configu= ration document that is not defined in 10.1. Is this really the bootstrap-= peer element in 10.1? Thanks, Dave > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, July 13, 2009 5:00 PM > To: i-d-announce@ietf.org > Cc: p2psip@ietf.org > Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Peer-to-Peer Session Initiation > Protocol Working Group of the IETF. >=20 >=20 > Title : REsource LOcation And Discovery (RELOAD) Base > Protocol > Author(s) : C. Jennings, et al. > Filename : draft-ietf-p2psip-base-03.txt > Pages : 146 > Date : 2009-07-13 >=20 > In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC > 3979 respectively. They refer only to those RFCs and not any documents > that update or supersede them. >=20 > This document defines REsource LOcation And Discovery (RELOAD), a peer- > to-peer (P2P) signaling protocol for use on the Internet. A P2P > signaling protocol provides its clients with an abstract storage and > messaging service between a set of cooperating peers that form the > overlay network. RELOAD is designed to support a P2P Session > Initiation Protocol (P2PSIP) network, but can be utilized by other > applications with similar requirements by defining new usages that > specify the kinds of data that must be stored for a particular > application. RELOAD defines a security model based on a certificate > enrollment service that provides unique identities. NAT traversal is a > fundamental service of the protocol. RELOAD also allows access from > "client" nodes that do not need to route traffic or store data for > others. >=20 > Legal >=20 > This documents and the information contained therein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From bbl@lowekamp.net Tue Jul 14 20:44:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C593A6862 for ; Tue, 14 Jul 2009 20:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTzg2XMbl-il for ; Tue, 14 Jul 2009 20:44:34 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id BF2973A67FE for ; Tue, 14 Jul 2009 20:44:33 -0700 (PDT) Received: by fxm18 with SMTP id 18so3199338fxm.37 for ; Tue, 14 Jul 2009 20:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.145 with SMTP id c17mr3438346fas.102.1247629397428; Tue, 14 Jul 2009 20:43:17 -0700 (PDT) In-Reply-To: <20090714000001.D94FA28C458@core3.amsl.com> References: <20090714000001.D94FA28C458@core3.amsl.com> Date: Tue, 14 Jul 2009 23:43:17 -0400 Message-ID: From: Bruce Lowekamp To: p2psip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 03:44:35 -0000 Here is the change log for p2psip-base-03: * Rearranged forwarding header to fix alignment among other issues * Removed route logging * Switched to binary ICE for Attach * ConfigUpdate improved * Change from close DTLS session on fragmentation attack to drop fragments, indirect attack * Updates to trivial sender/receiver text * Updates to data model based on list discussion * Updates to chord overlay algorithm section * Added AppAttach and removed port number from Attach * Changed via-list to use shorter structure * Rewrote fragmentation * Moved AIMD and TFRC congestion control algorithms to appendix until further wg effort decides direction there. For a more thorough view of changes, take a look at the diff http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-base-03.txt Bruce On Mon, Jul 13, 2009 at 8:00 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Peer-to-Peer Session Initiation Protocol= Working Group of the IETF. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : REs= ource LOcation And Discovery (RELOAD) Base Protocol > =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : C. Jennings, = et al. > =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ie= tf-p2psip-base-03.txt > =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 146 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 2009-07-13 > > In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC > 3979 respectively. =C2=A0They refer only to those RFCs and not any > documents that update or supersede them. > > This document defines REsource LOcation And Discovery (RELOAD), a > peer-to-peer (P2P) signaling protocol for use on the Internet. =C2=A0A P2= P > signaling protocol provides its clients with an abstract storage and > messaging service between a set of cooperating peers that form the > overlay network. =C2=A0RELOAD is designed to support a P2P Session > Initiation Protocol (P2PSIP) network, but can be utilized by other > applications with similar requirements by defining new usages that > specify the kinds of data that must be stored for a particular > application. =C2=A0RELOAD defines a security model based on a certificate > enrollment service that provides unique identities. =C2=A0NAT traversal i= s > a fundamental service of the protocol. =C2=A0RELOAD also allows access > from "client" nodes that do not need to route traffic or store data > for others. > > Legal > > This documents and the information contained therein are provided on > an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > FOR A PARTICULAR PURPOSE. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From bbl@lowekamp.net Tue Jul 14 21:05:48 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9068E3A67D4 for ; Tue, 14 Jul 2009 21:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRVZeuJG8W4H for ; Tue, 14 Jul 2009 21:05:47 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id A22453A67D3 for ; Tue, 14 Jul 2009 21:05:47 -0700 (PDT) Received: by fxm18 with SMTP id 18so3204588fxm.37 for ; Tue, 14 Jul 2009 21:04:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.145 with SMTP id c17mr3440306fas.102.1247630295791; Tue, 14 Jul 2009 20:58:15 -0700 (PDT) Date: Tue, 14 Jul 2009 23:58:15 -0400 Message-ID: From: Bruce Lowekamp To: p2psip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] status of reload overlay link congestion control/reliability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 04:05:48 -0000 We had a lot of discussions on list about finding the right solution for hop-by-hop congestion control and reliability for the overlay link protocol. The author team also continued that discussion separately, and, honestly, made no progress. So the -03 draft has the following interim solution. - The main body of the draft includes a simple ack-based receiver and a stop and wait sender. - The TFRC and AIMD senders have been moved to an appendix. They work with the simple receiver. If TCP over UDP or a similar separate specification appears to gain traction toward standardization before reload is finished, we will support adopting such a solution in reload. If no such solution appears to be nearing consensus, we will have to revisit the best approach for a uncomplicated semi-reliable congestion control algorithm for UDP WAN links. Stop and wait is probably already fine for most LAN deployments. Bruce From bbl@lowekamp.net Tue Jul 14 21:19:48 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DEA3A67FE for ; Tue, 14 Jul 2009 21:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrGYRXanOspk for ; Tue, 14 Jul 2009 21:19:47 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 402E23A67D3 for ; Tue, 14 Jul 2009 21:19:47 -0700 (PDT) Received: by fxm18 with SMTP id 18so3207930fxm.37 for ; Tue, 14 Jul 2009 21:17:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.107.9 with SMTP id z9mr3440999fao.1.1247627131811; Tue, 14 Jul 2009 20:05:31 -0700 (PDT) In-Reply-To: <025b01c9fec9$489efb70$d9dcf250$%roni@huawei.com> References: <025b01c9fec9$489efb70$d9dcf250$%roni@huawei.com> Date: Tue, 14 Jul 2009 23:05:31 -0400 Message-ID: From: Bruce Lowekamp To: Roni Even Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 04:19:48 -0000 I would like to see a couple changes in how the ideas in this draft are implemented, but the concepts are basically sound. I would support adopting this draft as an extension. Section 3 should probably reflect in its discussion that the DRR and RPR responses require the establishment of a (D)TLS session before the message is exchanged. I think a precise analysis of the cost isn't necessary, but the diagrams are a bit misleading in how many messages are involved. In Section 5.2, why not implement IGNORE-STATE-KEEPING as a ForwardingOption with FORWARD_CRITICAL? The WG can then discuss whether to incorporate that into the base draft or leave it as an extension. Parenthetically, the state to be concerned about is not so much the hop-by-hop retransmission, but state that may be kept if the peer is keeping per-transaction forwarding state rather than encoding it in the via-list. Also in 5.2, with the changes in the via list structure, I think we need to revisit adding an IP address as a DestinationType in an extension. I think the ForwardingOption works, but it smells a bit too much like a hack to me. Bruce From julian@orchidseed.org Tue Jul 14 23:09:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE1E3A68B9 for ; Tue, 14 Jul 2009 23:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1gtKpeHjofc for ; Tue, 14 Jul 2009 23:09:15 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id E111A3A6828 for ; Tue, 14 Jul 2009 23:08:46 -0700 (PDT) Received: by yxe34 with SMTP id 34so3915963yxe.29 for ; Tue, 14 Jul 2009 23:07:54 -0700 (PDT) Received: by 10.90.50.5 with SMTP id x5mr3956161agx.56.1247638073837; Tue, 14 Jul 2009 23:07:53 -0700 (PDT) Received: from ?10.0.1.2? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 21sm8105321agb.35.2009.07.14.23.07.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 23:07:52 -0700 (PDT) Message-Id: <811B5F20-30B3-488E-80B9-244F72C65DC5@orchidseed.org> From: jc To: p2psip@ietf.org In-Reply-To: <20090714000001.D94FA28C458@core3.amsl.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-895413758 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 23:07:49 -0700 References: <20090714000001.D94FA28C458@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 06:09:17 -0000 --Apple-Mail-1-895413758 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit FYI: The sample xml configuration has open/end tag mismatches. 47112162e84c69ba 6eba45d31a900c06 jc On Jul 13, 2009, at 5:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Peer-to-Peer Session Initiation > Protocol Working Group of the IETF. > > > Title : REsource LOcation And Discovery (RELOAD) Base > Protocol > Author(s) : C. Jennings, et al. > Filename : draft-ietf-p2psip-base-03.txt > Pages : 146 > Date : 2009-07-13 > > In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC > 3979 respectively. They refer only to those RFCs and not any > documents that update or supersede them. > > This document defines REsource LOcation And Discovery (RELOAD), a > peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P > signaling protocol provides its clients with an abstract storage and > messaging service between a set of cooperating peers that form the > overlay network. RELOAD is designed to support a P2P Session > Initiation Protocol (P2PSIP) network, but can be utilized by other > applications with similar requirements by defining new usages that > specify the kinds of data that must be stored for a particular > application. RELOAD defines a security model based on a certificate > enrollment service that provides unique identities. NAT traversal is > a fundamental service of the protocol. RELOAD also allows access > from "client" nodes that do not need to route traffic or store data > for others. > > Legal > > This documents and the information contained therein are provided on > an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > FOR A PARTICULAR PURPOSE. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1-895413758 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable FYI: The sample xml = configuration has open/end tag = mismatches.

         =   <kind-signer> 47112162e84c69ba = <kind-signer>
         =   <kind-signer> 6eba45d31a900c06 = <kind-signer>

jc

On Jul 13, 2009, at 5:00 PM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the = Peer-to-Peer Session Initiation Protocol Working Group of the = IETF.


= Title =           : REsource = LOcation And Discovery (RELOAD) Base Protocol
Author(s) =       : C. Jennings, et al.
Filename =        : = draft-ietf-p2psip-base-03.txt
Pages =           : = 146
= Date =            : = 2009-07-13

In this document the term BCP 78 and BCP 79 refer to = RFC 3978 and RFC
3979 respectively.  They refer only to those = RFCs and not any
documents that update or supersede them.

This = document defines REsource LOcation And Discovery (RELOAD), = a
peer-to-peer (P2P) signaling protocol for use on the Internet. =  A P2P
signaling protocol provides its clients with an abstract = storage and
messaging service between a set of cooperating peers that = form the
overlay network.  RELOAD is designed to support a P2P = Session
Initiation Protocol (P2PSIP) network, but can be utilized by = other
applications with similar requirements by defining new usages = that
specify the kinds of data that must be stored for a = particular
application.  RELOAD defines a security model based = on a certificate
enrollment service that provides unique identities. =  NAT traversal is
a fundamental service of the protocol. =  RELOAD also allows access
from "client" nodes that do not need = to route traffic or store data
for others.

Legal

This = documents and the information contained therein are provided on
an = "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS = OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND = THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS = OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF = THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED = WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR = PURPOSE.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt
=
Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
<mime-attachment>____________= ___________________________________
P2PSIP mailing = list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

= --Apple-Mail-1-895413758-- From julian@orchidseed.org Wed Jul 15 01:22:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3416C3A6880 for ; Wed, 15 Jul 2009 01:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBmTkymWPzPU for ; Wed, 15 Jul 2009 01:22:31 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id 3DD103A684C for ; Wed, 15 Jul 2009 01:22:30 -0700 (PDT) Received: by yxe34 with SMTP id 34so3984675yxe.29 for ; Wed, 15 Jul 2009 01:20:17 -0700 (PDT) Received: by 10.90.33.16 with SMTP id g16mr3966138agg.65.1247638791289; Tue, 14 Jul 2009 23:19:51 -0700 (PDT) Received: from ?10.0.1.2? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 5sm1632673agc.15.2009.07.14.23.19.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 23:19:49 -0700 (PDT) Message-Id: From: jc To: p2psip@ietf.org In-Reply-To: <20090714000001.D94FA28C458@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 23:19:45 -0700 References: <20090714000001.D94FA28C458@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) Subject: Re: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 08:22:32 -0000 It is my opinion that the SRV Service name for enrollment server discovery be changed from "p2p_enroll" to "p2psip_enroll". jc On Jul 13, 2009, at 5:00 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Peer-to-Peer Session Initiation > Protocol Working Group of the IETF. > > > Title : REsource LOcation And Discovery (RELOAD) Base > Protocol > Author(s) : C. Jennings, et al. > Filename : draft-ietf-p2psip-base-03.txt > Pages : 146 > Date : 2009-07-13 > > In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC > 3979 respectively. They refer only to those RFCs and not any > documents that update or supersede them. > > This document defines REsource LOcation And Discovery (RELOAD), a > peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P > signaling protocol provides its clients with an abstract storage and > messaging service between a set of cooperating peers that form the > overlay network. RELOAD is designed to support a P2P Session > Initiation Protocol (P2PSIP) network, but can be utilized by other > applications with similar requirements by defining new usages that > specify the kinds of data that must be stored for a particular > application. RELOAD defines a security model based on a certificate > enrollment service that provides unique identities. NAT traversal is > a fundamental service of the protocol. RELOAD also allows access > from "client" nodes that do not need to route traffic or store data > for others. > > Legal > > This documents and the information contained therein are provided on > an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > FOR A PARTICULAR PURPOSE. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From davidbryan@gmail.com Wed Jul 15 09:29:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F093A6C1E for ; Wed, 15 Jul 2009 09:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwyTuNJyph39 for ; Wed, 15 Jul 2009 09:29:43 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id 7853A3A6947 for ; Wed, 15 Jul 2009 09:29:10 -0700 (PDT) Received: by gxk9 with SMTP id 9so2371884gxk.13 for ; Wed, 15 Jul 2009 09:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=zrKCS4vsKIxgKuCCm3VRcFmcWTecJ3+A1RpG8rRaOYM=; b=fbrVuuLH+bSGWTdj443i/NsszeuqApbZ/CDhvn58pC9qPNlogxTO2M87DGhoMLMvt1 3tOAbvE5ES2rXY07AKoomam2k3a5JkYOqPVdXTAABN15DMw9IyG+rwGrU8NlFb7nEbf3 Z3N9qIzkjDovf1C1bDitFOpE4ZfSBzYr6fxAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=ukOCAiY5kfskXNRemZsTSVsgtY0jgHXHnIN+enfXsFy9dyCbvaYzPP8I1dHn41o88j kW4BzOQk2L5wQoLAVUZHSpe4khcey7KUaNVHFDNf7XgK00STaCUAyVVjXVHz6T4e6nmt sxS8pS0jys/sG8vsWHYxJ/ontq6ecSOMZbh9s= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.51.2 with SMTP id y2mr12716893yby.217.1247672474502; Wed, 15 Jul 2009 08:41:14 -0700 (PDT) In-Reply-To: <20090714000001.D94FA28C458@core3.amsl.com> References: <20090714000001.D94FA28C458@core3.amsl.com> Date: Wed, 15 Jul 2009 08:41:14 -0700 X-Google-Sender-Auth: c19b547d1dcf529c Message-ID: <8b2769930907150841u293c159bl286c71af9dbb55f1@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:29:44 -0000 First off, thanks to the authors for getting the new version out. It's a great deal of work to revise it and we appreciate it. At the last meeting in San Francisco, I asked for volunteers to review the next version as soon as it came out. Now that it is out, I would like to ask the volunteers we had (Vidya Narayana, Saumitra Das, Melody Song, and myself) to please now do a review. (I've already started mine) I know that the editors would really appreciate the feedback, and as WG chairs, we want to get the draft moving forward, and getting formal reviews. Also, if there are any other volunteers willing to do a complete review, please drop me an email. I'd like to have these reviews as soon as possible. Also: thanks to Dave Craig, who I noticed already sent very substantial comments on the new draft. Thanks, David (as chair) On Mon, Jul 13, 2009 at 5:00 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. > > > Title : REsource LOcation And Discovery (RELOAD) Base Protocol > Author(s) : C. Jennings, et al. > Filename : draft-ietf-p2psip-base-03.txt > Pages : 146 > Date : 2009-07-13 > > In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC > 3979 respectively. They refer only to those RFCs and not any > documents that update or supersede them. > > This document defines REsource LOcation And Discovery (RELOAD), a > peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P > signaling protocol provides its clients with an abstract storage and > messaging service between a set of cooperating peers that form the > overlay network. RELOAD is designed to support a P2P Session > Initiation Protocol (P2PSIP) network, but can be utilized by other > applications with similar requirements by defining new usages that > specify the kinds of data that must be stored for a particular > application. RELOAD defines a security model based on a certificate > enrollment service that provides unique identities. NAT traversal is > a fundamental service of the protocol. RELOAD also allows access > from "client" nodes that do not need to route traffic or store data > for others. > > Legal > > This documents and the information contained therein are provided on > an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > FOR A PARTICULAR PURPOSE. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From davidbryan@gmail.com Wed Jul 15 09:51:48 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A933A6F20 for ; Wed, 15 Jul 2009 09:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFqu77nHfv6X for ; Wed, 15 Jul 2009 09:51:48 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id E2F9A3A6F30 for ; Wed, 15 Jul 2009 09:51:47 -0700 (PDT) Received: by yxe34 with SMTP id 34so4420495yxe.29 for ; Wed, 15 Jul 2009 09:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k28XilJgGnp5NRLVpmEpCypeb03juxR0FDUrd70wOcI=; b=vkjxYJ9QAxMeln3p6C+t5YUmPeXDljDax8+P3JDpU/nT0ivwbntom1Df7zxgMg3fPz 5rqx8yDY9gGx6kH7RSLZb0WYbnjHdIGQ6NV1zIG5d9ebfCyNWjp9bSuA/8CPfM+CQtzY GJ0c/TbBQf17kjSUraS/r53b0yEGF2y/WHQdY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=jK3NoXnnugC8WVoGX8cKp0shpuMKk1+Tiyd/+quHluRRFhdNFkQclMz/8GtP7pHRNE ot/FYx4/ce6WbktG27h+dE99LWuYthqWXd2Ml+TW3acNRUITSp2LlwFkAt5Er+wjQRff pmkJAT3wiWYoWPd385PAfEy2nADh1qZx6sWRs= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.137.13 with SMTP id k13mr12805245ybd.54.1247671737326; Wed, 15 Jul 2009 08:28:57 -0700 (PDT) Date: Wed, 15 Jul 2009 08:28:57 -0700 X-Google-Sender-Auth: 8623f463440a0fd0 Message-ID: <8b2769930907150828n11467454iaef9951e4d6a2196@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Draft agenda for IETF-75 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 16:51:48 -0000 We had man submissions for IETF-75, and as usual, we weren't able to accommodate them all. Web version of the agenda with links to the drafts: http://www.ietf.org/proceedings/09jul/agenda/p2psip.html P2PSIP, IETF-75, Stockholm, Sweden Large Stage Tuesday, July 28, 2009, 1520-1810 (2:50) Proposed agenda: Agenda Bash, chairs, 10 minutes, 1520-1530 RELOAD base draft, Eric Rescorla, draft-ietf-p2psip-base-03, 1 hour 35 minutes, 1530-1705 eclients draft, Vidya Nayayanan, draft-vidya-p2psip-eclients-00, 20 minutes, 1705-1725 Diagnostics draft, Speaker TBD, draft-ietf-p2psip-diagnostics-01, 15 minutes, 1725-1740 Security Requirements draft, Speaker TBD, draft-matuszewski-p2psip-security-requirements-05, 15 minutes, 1740-1755 Relay draft, Speaker TBD, draft-jiang-p2psip-relay-02, 15 minutes, 1755-1810 As usual, time was reserved for WG items, items with significant list discussion, and revisions that the WG asked for at the last meeting (i.e., people who spoke and the WG asked them to specifically change the doc in some way). We also considered if a document was in scope -- as chartered right now, the WG is only considering the use of P2P for SIP -- not for other applications -- and we won't use WG time for items that are out of scope (although nothing stops discussion on list!). If you have agenda time and are listed as speaker TBD, please let Brian and I know off list who will be speaking. If you think we missed you (you asked for a slot, topic is in scope, and there was significant discussion on list), let me and Brian know off list. Please point to the discussion on list or action items from a previous meeting presentation if you send us an email. See you in Stockholm! David (as chair) From jiang.x.f@huawei.com Wed Jul 15 18:54:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6536B3A6B76 for ; Wed, 15 Jul 2009 18:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyT0S9mLyU5I for ; Wed, 15 Jul 2009 18:54:21 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 1E5693A69D9 for ; Wed, 15 Jul 2009 18:54:21 -0700 (PDT) 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 <0KMU00M2DQNEUV@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 16 Jul 2009 09:54:50 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMU00HMYQNE1K@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 16 Jul 2009 09:54:50 +0800 (CST) Received: from j36340a ([10.164.12.19]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMU00E6FQNE1A@szxml06-in.huawei.com> for p2psip@ietf.org; Thu, 16 Jul 2009 09:54:50 +0800 (CST) Date: Thu, 16 Jul 2009 09:54:50 +0800 From: jiangxingfeng In-reply-to: To: 'Bruce Lowekamp' , 'Roni Even' Message-id: <002101ca05b8$67a41b90$130ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcoFA59aJOofSoCXS7qBRVULe8w3KwArxNsg Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 01:54:22 -0000 Hi, Bruce: Thanks for advice. Some responses in line. Regards Jiang XingFeng > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > Bruce Lowekamp > Sent: Wednesday, July 15, 2009 11:06 AM > To: Roni Even > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02 > > I would like to see a couple changes in how the ideas in this draft > are implemented, but the concepts are basically sound. I would > support adopting this draft as an extension. Thanks! > > Section 3 should probably reflect in its discussion that the DRR and > RPR responses require the establishment of a (D)TLS session before the > message is exchanged. I think a precise analysis of the cost isn't > necessary, but the diagrams are a bit misleading in how many messages > are involved. Right. I think it is better to illustrate transport connections between peers. (D)TLS Connections between peers or between source peers and relay peers are reused to send the requests. But for responses, in common case, (D)TLS connections should be established between destination peers and relay peers or source peers. Authors will improve the diagram in next version. > > In Section 5.2, why not implement IGNORE-STATE-KEEPING as a > ForwardingOption with FORWARD_CRITICAL? The WG can then discuss > whether to incorporate that into the base draft or leave it as an > extension. Parenthetically, the state to be concerned about is not so > much the hop-by-hop retransmission, but state that may be kept if the > peer is keeping per-transaction forwarding state rather than encoding > it in the via-list. The reason for defining IGNORE-STATE-KEEPING as a flag in forwarding header is there were a flag field in ForwardingHeader. I just noticed that flags field (unit16) has been removed in base-03. Adding IGNORE-STATE-KEEPING is to avoid intermediate peers keeping state in order to forward response what SRR requires if DRR or RPR will be used. If intermediate peers still keep per-transaction forwarding state in case of DRR or RPR, the state will have to expire when timer fired. I think it's feasible to define a new extension to implement IGNORE-STATE-KEEPING. It's up to WG decide which one will choose. A little concern about using a new forwarding option: if several forwarding options are in the same requests, so what's the relationship between forwarding options? IMO, some options are related, so peers need process them in atomic way. But some are irrelevant, so peers can process them in independent way. > > Also in 5.2, with the changes in the via list structure, I think we > need to revisit adding an IP address as a DestinationType in an > extension. I think the ForwardingOption works, but it smells a bit > too much like a hack to me. Do you mean we need replace ExtensiveRoutingModeOption with a new type of destination? The only idea in my mind for how to achieve it is to make intermediate peers change its ways to encode via-list in case of RPR and DRR. Via-lists are populated by the source peers based on information of source peer and relay peers. In case of DRR and RPR, intermediate peers won't change via-list in transit. So that destination peers can use the via-lists to construct destination list for response. I think it works. Is that the same in your mind? > > Bruce > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From abcdmatao@gmail.com Wed Jul 15 23:38:40 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC1E3A6A2C for ; Wed, 15 Jul 2009 23:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[AWL=1.316, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5NEPgkZXV0A for ; Wed, 15 Jul 2009 23:38:34 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id 86F6D3A6895 for ; Wed, 15 Jul 2009 23:38:34 -0700 (PDT) Received: by yxe34 with SMTP id 34so5162973yxe.29 for ; Wed, 15 Jul 2009 23:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=qx9YhBCClrNCUrc5NI8beI+fZvOQ1i85VtU+n2aloEI=; b=MNn3rNY/NiJvQ0+6xZEnDKvXX+xRQ+5UeOuocQpz2ZBaQTYWxIN0q+iavnnSwsSEhm +2eFHpP6mwPk4onx9d77hdKiw/G5CD4n80CJbAusUDXG39u7NT+dsHOs6RkLAqKJYSng MdPyXWISWqMUe9O4F9pfZcVd2WVB6pNSURxYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=cmsz0LUgtcyS+bCG4nrLh5w6MoKhejSNUbjlXGETk0lgHilMmpYLqFSHB929UGXvFN JK++bnovOoGqbEzoaL4DSfQJEukHcHps8qOpwLJeNrfcHFbb6UrzEpe1KdIcESXA6INK y3WBpRC/PmjUGAYowXCI8NjL4m8wr2JT8mXec= MIME-Version: 1.0 Received: by 10.151.41.12 with SMTP id t12mr13987838ybj.199.1247726233016; Wed, 15 Jul 2009 23:37:13 -0700 (PDT) Date: Thu, 16 Jul 2009 14:37:13 +0800 Message-ID: <99978d7d0907152337pceb37b3r259eeaa813e4ab9a@mail.gmail.com> From: Tao Ma To: shen.jiong@zte.com.cn, p2psip@ietf.org Content-Type: multipart/alternative; boundary=0015175114aee55c48046ecce68b Cc: standardMINE@googlegroups.com Subject: Re: [P2PSIP] New draft on content sharing usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 06:38:40 -0000 --0015175114aee55c48046ecce68b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, As [draft-ietf-p2psip-base-03] said: =93RELOAD is designed to support a variety of applications, including P2P multimedia communications with the Session Initiation Protocol [I-D.ietf-p2psip-sip]. RELOAD allows the definition of new application usages. =94 I think this draft has given an example following this guideline. There is still one important issue to be badly noticed and discussed: For RELOAD is =93designed specifically to meet the requirements for a P2P protocol to support SIP=94 [draft-ietf-p2psip-base-03], it is applied to support content sharing in this draft, are there some specific requirements for content sharing usage that are too different from the SIP usage for RELOAD to support ? Or if you would make some extensions, which part needs extension and to what extent? I think this question would be general for all the P2P application usage which is inclined to use RELOAD. It is necessary to clarify the specific requirements, especially those are not supported well by current RELOAD. Regards Tao Ma 16th, July, 2009 Mobile Life New Media Lab, Beijing University of Posts and Telecommunications On Wed, Jul 1, 2009 at 9:16 AM, wrote: > > Hi all, > > We have submitted a draft on content sharing usage for RELOAD. It provides > the functionality of distributing and fetching shared content efficiently to > and from a P2P overlay network, which performs as Content Delivery Network > and is service insensitive. > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-shen-p2psip-content-sharing-00.= txt. > Comments are welcome. > > > Thanks, > Jiong > > > -------------------------------------------------------- > --0015175114aee55c48046ecce68b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,

  As [draft-ietf-p2psip-ba= se-03] said: “RELOAD is designed to support a variety of applications, including P2P multimedia communications with the Session Initiation Protocol [I-D.ietf-p2psip-sip]. RELOAD allows the definition of new application usages. ” I think thi= s draft has given an example following this guideline. There is still one important iss= ue to be badly noticed and discussed:

= For RELOAD is “designed specifically to meet the requirements for a P2P protocol to support SIP” [draft-ietf-p2psip-base-03], it is appli= ed to support content sharing in this draft, are there some specific requirements= for content sharing usage that are too different from the SIP usage for RELOAD = to support ? Or if you would make some extensions, which part needs extension = and to what extent?

  I think this question wo= uld be general for all the P2P application usage which is inclined to use RELOAD. It is necess= ary to clarify the specific requirements, especially those are not supported we= ll by current RELOAD.

   Regards

Tao Ma

16th, July,= 2009

Mobile Life New Media Lab, Beij= ing University of Posts and Telecommunications


On Wed, =
Jul 1, 2009 at 9:16 AM, <shen.jiong at zte=
.com.cn> wrote:


>

> Hi all,

>

> We have submitted a dr=
aft on content sharing usage for RELOAD. It
provides

> the fun=
ctionality of distributing and fetching shared content efficiently
to

> and from a P2P overlay network, which performs as Content Delivery=

Network

> and is service insensitive.

>

>=
 The draft can be found at

> http://www.ietf.org/in=
ternet-drafts/draft-shen-p2psip-content-sharing-00.txt.


>  Comments are welcome.

>

>

> Th=
anks,

> Jiong

>

>

> ---------------=
-----------------------------------------

>
 =20 --0015175114aee55c48046ecce68b-- From bbl@lowekamp.net Thu Jul 16 19:46:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936E33A6E12 for ; Thu, 16 Jul 2009 19:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnvFkp2u+s7b for ; Thu, 16 Jul 2009 19:46:31 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 6E1F73A6E1B for ; Thu, 16 Jul 2009 19:46:31 -0700 (PDT) Received: by fxm18 with SMTP id 18so481735fxm.37 for ; Thu, 16 Jul 2009 19:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.66 with SMTP id b2mr92549fas.3.1247798816140; Thu, 16 Jul 2009 19:46:56 -0700 (PDT) Date: Thu, 16 Jul 2009 22:46:56 -0400 Message-ID: From: Bruce Lowekamp To: p2psip Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] clients in reload and Update X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 02:46:32 -0000 Based on some of the list discussion, we (mostly ekr) tried to improve some of the text surrounding clients in the draft. I hope this clarifies some of the intent of how clients are supported by the base protocol. I also added some text to send Update requests to all nodes in the Connection Table when a peer's responsible ID range changes. The intention of this change was to provide a mechanism where a node attaching to a peer because it is responsible for a particular ID be notified if the peer is no longer responsible for the desired ID. This change also doesn't require the peer to determine why a particular connection is established, which preseves the generality of the current approach. Unfortunately, the implication of sending Updates to clients is that clients are required to process Updates. This is in conflict with the goal that clients don't need to implement the overlay algorithm used by the overlay (since Update's content is defined by the overlay algorithm). I see a few solutions to this problem: 1) rely on the clients to periodically Ping or Route_Query to ensure they are connected to the correct peer. Unfortunately, this leaves an obvious gap before the topology change is noticed. Unlike sip-outbound, we don't have redundant connections to compensate for temporary loss of reachability. 2) define a new method for this purpose that is generic, so independent of overlay algorithm 3) retain the current use of Update, and specify that a client receiving an Update that it cannot process (because it does not speak the overlay algorithm) SHOULD perform a Route_Query to confirm it is still connected to the proper peer. My personal preference is option 3, because I dislike the performance tradeoffs of option 1, and I think option 3 has all of the functionality option 2 would have anyway. On a slightly separate note, I'm a bit concerned about the ability to establish a client's ability to establish a reliable connection with its responsible peer. In Chord, for example, greater reliability would be achieved by establishing a connection with the responsible peer and n successors. If a peer receives a message routed to a node for which it is responsible but has no connection, it could then forward that message to its n successors to attempt to deliver it. Currently the peer would drop the message silently. My current feeling is that such a feature should be left for an extension. Bruce From bbl@lowekamp.net Thu Jul 16 20:08:27 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075FC3A6805 for ; Thu, 16 Jul 2009 20:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktJNtSZ4La46 for ; Thu, 16 Jul 2009 20:08:26 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 130B43A6A05 for ; Thu, 16 Jul 2009 20:08:25 -0700 (PDT) Received: by fxm18 with SMTP id 18so487320fxm.37 for ; Thu, 16 Jul 2009 20:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.9 with SMTP id r9mr92431fao.66.1247800137215; Thu, 16 Jul 2009 20:08:57 -0700 (PDT) In-Reply-To: References: <20090714000001.D94FA28C458@core3.amsl.com> Date: Thu, 16 Jul 2009 23:08:57 -0400 Message-ID: From: Bruce Lowekamp To: "Craig, Dave" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 03:08:27 -0000 Dave, Thanks for your detailed read and comments. Going to try to incorporate them into the next update. 2009/7/14 Craig, Dave : > 9. In 5.6.2.2.1. fifth paragraph, was the following intended? =C2=A0"If a= ll retransmissions for a message fail, _the sending node should close the c= onnection routing the message_." =C2=A0Should there also be additional hyst= eresis to make sure that a failing connection is not quickly reestablished = under a fast chord-reload-ping-frequency? > Yes, that sentence should have finished that the link has failed and the connection be closed. Actually, ping-frequency doesn't come into play very much here. First, it's very long, and second, the algorithm uses randomness in its finger table searches, trying to avoid this problem. It's more of an issue for neighbor connections, which are tried more aggressively. But if you're using periodic recovery, you get that automatic bit of hysteresis. A reactive recovery implementation probably would want to detect and avoid rapid oscillations, but the draft doesn't go into that detail right now. Probably it should mention it. Bruce From shen.jiong@zte.com.cn Fri Jul 17 00:02:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BB33A6E22 for ; Fri, 17 Jul 2009 00:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.012 X-Spam-Level: X-Spam-Status: No, score=-92.012 tagged_above=-999 required=5 tests=[AWL=-1.823, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk71cJCBFVPb for ; Fri, 17 Jul 2009 00:02:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id E85813A68D5 for ; Fri, 17 Jul 2009 00:02:52 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111642075036648; Fri, 17 Jul 2009 14:14:40 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 85804.9021923151; Fri, 17 Jul 2009 14:24:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6H6LjQu094747; Fri, 17 Jul 2009 14:21:53 +0800 (CST) (envelope-from shen.jiong@zte.com.cn) In-Reply-To: <99978d7d0907152337pceb37b3r259eeaa813e4ab9a@mail.gmail.com> To: Tao Ma MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: shen.jiong@zte.com.cn Date: Fri, 17 Jul 2009 14:21:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-17 14:21:46, Serialize complete at 2009-07-17 14:21:46 Content-Type: multipart/alternative; boundary="=_alternative 0022F9C5482575F6_=" X-MAIL: mse2.zte.com.cn n6H6LjQu094747 Cc: p2psip@ietf.org, standardMINE@googlegroups.com Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBOZXcgZHJhZnQgb24gY29udGVudCBz?= =?gb2312?b?aGFyaW5nIHVzYWdlIGZvciBSRUxPQUQ=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 07:02:55 -0000 This is a multipart message in MIME format. --=_alternative 0022F9C5482575F6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVGFvLA0KDQpCYXNlZCBvbiB0aGUgcGVjdWxpYXJpdHkgb2YgdGhlIGNvbnRlbnQgc2hhcmlu ZyB1c2FnZSwgdGhlIGNvbnRlbnQgDQpub3JtYWxseSBpcyBodWdlLiBTbyBuZWVkIGNvbnNpZGVy IG9mICBsb2FkIGJhbmxhbmNlIGFyaXRobWV0aWMsIHRvcG9sb2d5IA0Kb3B0aW1pemUgYW5kIHRo ZSBydWxlcyBmb3Igc2xpY2UgdmVyeSBodWdlIGNvbnRlbnQgdG8gc2VnbWVudHMuDQoNClRoYW5r cywNCkppb25nDQoNCg0KDQoNCg0KVGFvIE1hIDxhYmNkbWF0YW9AZ21haWwuY29tPiANCjIwMDkt MDctMTYgMTQ6MzcNCg0KytW8/sjLDQpzaGVuLmppb25nQHp0ZS5jb20uY24sIHAycHNpcEBpZXRm Lm9yZw0Ks63LzQ0KbGlsaWNodW4gPGxpbGljaHVuQGdtYWlsLmNvbT4sIHpoYW5nY2hAYnVwdC5l ZHUuY24sIA0Kc3RhbmRhcmRNSU5FQGdvb2dsZWdyb3Vwcy5jb20NCtb3zOINClJlOiBbUDJQU0lQ XSBOZXcgZHJhZnQgb24gY29udGVudCBzaGFyaW5nIHVzYWdlIGZvciBSRUxPQUQNCg0KDQoNCg0K DQoNCkhpLA0KICBBcyBbZHJhZnQtaWV0Zi1wMnBzaXAtYmFzZS0wM10gc2FpZDogobBSRUxPQUQg aXMgZGVzaWduZWQgdG8gc3VwcG9ydCBhIA0KdmFyaWV0eSBvZiBhcHBsaWNhdGlvbnMsIGluY2x1 ZGluZyBQMlAgbXVsdGltZWRpYSBjb21tdW5pY2F0aW9ucyB3aXRoIHRoZSANClNlc3Npb24gSW5p dGlhdGlvbiBQcm90b2NvbCBbSS1ELmlldGYtcDJwc2lwLXNpcF0uIFJFTE9BRCBhbGxvd3MgdGhl IA0KZGVmaW5pdGlvbiBvZiBuZXcgYXBwbGljYXRpb24gdXNhZ2VzLiChsSBJIHRoaW5rIHRoaXMg ZHJhZnQgaGFzIGdpdmVuIGFuIA0KZXhhbXBsZSBmb2xsb3dpbmcgdGhpcyBndWlkZWxpbmUuIFRo ZXJlIGlzIHN0aWxsIG9uZSBpbXBvcnRhbnQgaXNzdWUgdG8gYmUgDQpiYWRseSBub3RpY2VkIGFu ZCBkaXNjdXNzZWQ6DQpGb3IgUkVMT0FEIGlzIKGwZGVzaWduZWQgc3BlY2lmaWNhbGx5IHRvIG1l ZXQgdGhlIHJlcXVpcmVtZW50cyBmb3IgYSBQMlAgDQpwcm90b2NvbCB0byBzdXBwb3J0IFNJUKGx IFtkcmFmdC1pZXRmLXAycHNpcC1iYXNlLTAzXSwgaXQgaXMgYXBwbGllZCB0byANCnN1cHBvcnQg Y29udGVudCBzaGFyaW5nIGluIHRoaXMgZHJhZnQsIGFyZSB0aGVyZSBzb21lIHNwZWNpZmljIA0K cmVxdWlyZW1lbnRzIGZvciBjb250ZW50IHNoYXJpbmcgdXNhZ2UgdGhhdCBhcmUgdG9vIGRpZmZl cmVudCBmcm9tIHRoZSBTSVAgDQp1c2FnZSBmb3IgUkVMT0FEIHRvIHN1cHBvcnQgPyBPciBpZiB5 b3Ugd291bGQgbWFrZSBzb21lIGV4dGVuc2lvbnMsIHdoaWNoIA0KcGFydCBuZWVkcyBleHRlbnNp b24gYW5kIHRvIHdoYXQgZXh0ZW50Pw0KICBJIHRoaW5rIHRoaXMgcXVlc3Rpb24gd291bGQgYmUg Z2VuZXJhbCBmb3IgYWxsIHRoZSBQMlAgYXBwbGljYXRpb24gdXNhZ2UgDQp3aGljaCBpcyBpbmNs aW5lZCB0byB1c2UgUkVMT0FELiBJdCBpcyBuZWNlc3NhcnkgdG8gY2xhcmlmeSB0aGUgc3BlY2lm aWMgDQpyZXF1aXJlbWVudHMsIGVzcGVjaWFsbHkgdGhvc2UgYXJlIG5vdCBzdXBwb3J0ZWQgd2Vs bCBieSBjdXJyZW50IFJFTE9BRC4gDQogICBSZWdhcmRzDQpUYW8gTWENCjE2dGgsIEp1bHksIDIw MDkNCk1vYmlsZSBMaWZlIE5ldyBNZWRpYSBMYWIsIEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0 cyBhbmQgDQpUZWxlY29tbXVuaWNhdGlvbnMNCg0KT24gV2VkLCBKdWwgMSwgMjAwOSBhdCA5OjE2 IEFNLCA8c2hlbi5qaW9uZyBhdCB6dGUuY29tLmNuPiB3cm90ZToNCg0KDQo+DQoNCj4gSGkgYWxs LA0KDQo+DQoNCj4gV2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdCBvbiBjb250ZW50IHNoYXJpbmcg dXNhZ2UgZm9yIFJFTE9BRC4gSXQNCnByb3ZpZGVzDQoNCj4gdGhlIGZ1bmN0aW9uYWxpdHkgb2Yg ZGlzdHJpYnV0aW5nIGFuZCBmZXRjaGluZyBzaGFyZWQgY29udGVudCANCmVmZmljaWVudGx5DQp0 bw0KDQoNCj4gYW5kIGZyb20gYSBQMlAgb3ZlcmxheSBuZXR3b3JrLCB3aGljaCBwZXJmb3JtcyBh cyBDb250ZW50IERlbGl2ZXJ5DQpOZXR3b3JrDQoNCj4gYW5kIGlzIHNlcnZpY2UgaW5zZW5zaXRp dmUuDQoNCj4NCg0KPiBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0DQoNCj4gDQpodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zaGVuLXAycHNpcC1jb250ZW50LXNoYXJp bmctMDAudHh0DQouDQoNCg0KPiAgQ29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCj4NCg0KPg0KDQo+ IFRoYW5rcywNCg0KPiBKaW9uZw0KDQo+DQoNCj4NCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+DQogDQoNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24u IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVy bWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8g b3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJl IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNj YW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0022F9C5482575F6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj5IaSBUYW8sPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+QmFzZWQgb24gdGhlIHBlY3VsaWFyaXR5IG9mIHRo ZSBjb250ZW50IHNoYXJpbmcNCnVzYWdlLCB0aGUgY29udGVudCBub3JtYWxseSBpcyBodWdlLiBT byBuZWVkIGNvbnNpZGVyIG9mICZuYnNwO2xvYWQgYmFubGFuY2UNCmFyaXRobWV0aWMsIHRvcG9s b2d5IG9wdGltaXplIGFuZCB0aGUgcnVsZXMgZm9yIHNsaWNlIHZlcnkgaHVnZSBjb250ZW50DQp0 byBzZWdtZW50cy48L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTEwMCU+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPlRo YW5rcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj5KaW9uZzwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj5UYW8gTWEgJmx0O2FiY2RtYXRhb0BnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDctMTYgMTQ6Mzc8L2ZvbnQ+DQo8dGQg d2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+c2hlbi5qaW9uZ0B6 dGUuY29tLmNuLCBwMnBzaXBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmxpbGljaHVuICZs dDtsaWxpY2h1bkBnbWFpbC5jb20mZ3Q7LA0KemhhbmdjaEBidXB0LmVkdS5jbiwgc3RhbmRhcmRN SU5FQGdvb2dsZWdyb3Vwcy5jb208L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbUDJQU0lQXSBOZXcg ZHJhZnQgb24gY29udGVudCBzaGFyaW5nDQp1c2FnZSBmb3IgUkVMT0FEPC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PkhpLDwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgQXMg W2RyYWZ0LWlldGYtcDJwc2lwLWJhc2UtMDNdDQpzYWlkOiChsFJFTE9BRCBpcyBkZXNpZ25lZCB0 byBzdXBwb3J0IGEgdmFyaWV0eSBvZiBhcHBsaWNhdGlvbnMsIGluY2x1ZGluZw0KUDJQIG11bHRp bWVkaWEgY29tbXVuaWNhdGlvbnMgd2l0aCB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29s IFtJLUQuaWV0Zi1wMnBzaXAtc2lwXS4NClJFTE9BRCBhbGxvd3MgdGhlIGRlZmluaXRpb24gb2Yg bmV3IGFwcGxpY2F0aW9uIHVzYWdlcy4gobEgSSB0aGluayB0aGlzDQpkcmFmdCBoYXMgZ2l2ZW4g YW4gZXhhbXBsZSBmb2xsb3dpbmcgdGhpcyBndWlkZWxpbmUuIFRoZXJlIGlzIHN0aWxsIG9uZQ0K aW1wb3J0YW50IGlzc3VlIHRvIGJlIGJhZGx5IG5vdGljZWQgYW5kIGRpc2N1c3NlZDo8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Rm9yIFJFTE9BRCBpcyChsGRlc2ln bmVkIHNwZWNpZmljYWxseQ0KdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIGZvciBhIFAyUCBwcm90 b2NvbCB0byBzdXBwb3J0IFNJUKGxIFtkcmFmdC1pZXRmLXAycHNpcC1iYXNlLTAzXSwNCml0IGlz IGFwcGxpZWQgdG8gc3VwcG9ydCBjb250ZW50IHNoYXJpbmcgaW4gdGhpcyBkcmFmdCwgYXJlIHRo ZXJlIHNvbWUNCnNwZWNpZmljIHJlcXVpcmVtZW50cyBmb3IgY29udGVudCBzaGFyaW5nIHVzYWdl IHRoYXQgYXJlIHRvbyBkaWZmZXJlbnQNCmZyb20gdGhlIFNJUCB1c2FnZSBmb3IgUkVMT0FEIHRv IHN1cHBvcnQgPyBPciBpZiB5b3Ugd291bGQgbWFrZSBzb21lIGV4dGVuc2lvbnMsDQp3aGljaCBw YXJ0IG5lZWRzIGV4dGVuc2lvbiBhbmQgdG8gd2hhdCBleHRlbnQ/PC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJIHRoaW5rIHRoaXMgcXVlc3Rpb24gd291 bGQgYmUNCmdlbmVyYWwgZm9yIGFsbCB0aGUgUDJQIGFwcGxpY2F0aW9uIHVzYWdlIHdoaWNoIGlz IGluY2xpbmVkIHRvIHVzZSBSRUxPQUQuDQpJdCBpcyBuZWNlc3NhcnkgdG8gY2xhcmlmeSB0aGUg c3BlY2lmaWMgcmVxdWlyZW1lbnRzLCBlc3BlY2lhbGx5IHRob3NlDQphcmUgbm90IHN1cHBvcnRl ZCB3ZWxsIGJ5IGN1cnJlbnQgUkVMT0FELiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1JlZ2FyZHM8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+VGFvIE1hPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPjE2dGgsIEp1bHksIDIwMDk8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+TW9iaWxlIExpZmUgTmV3IE1lZGlhIExhYiwgQmVpamluZyBVbml2ZXJzaXR5 DQpvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zPC9mb250Pg0KPHA+DQo8cD48dHQ+PGZv bnQgc2l6ZT0yPk9uIFdlZCwgSnVsIDEsIDIwMDkgYXQgOToxNiBBTSwgJmx0O3NoZW4uamlvbmcg YXQgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwOi8venRlLmNvbS5jbi8+PHR0Pjxmb250IHNpemU9 MiBjb2xvcj1ibHVlPjx1Pnp0ZS5jb20uY248L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBz aXplPTI+Jmd0Ow0Kd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KJmd0Ozxicj4NCjxicj4NCiZndDsg SGkgYWxsLDxicj4NCjxicj4NCiZndDs8YnI+DQo8YnI+DQomZ3Q7IFdlIGhhdmUgc3VibWl0dGVk IGEgZHJhZnQgb24gY29udGVudCBzaGFyaW5nIHVzYWdlIGZvciBSRUxPQUQuIEl0PGJyPg0KcHJv dmlkZXM8YnI+DQo8YnI+DQomZ3Q7IHRoZSBmdW5jdGlvbmFsaXR5IG9mIGRpc3RyaWJ1dGluZyBh bmQgZmV0Y2hpbmcgc2hhcmVkIGNvbnRlbnQgZWZmaWNpZW50bHk8YnI+DQp0bzxicj4NCjxicj4N Cjxicj4NCiZndDsgYW5kIGZyb20gYSBQMlAgb3ZlcmxheSBuZXR3b3JrLCB3aGljaCBwZXJmb3Jt cyBhcyBDb250ZW50IERlbGl2ZXJ5PGJyPg0KTmV0d29yazxicj4NCjxicj4NCiZndDsgYW5kIGlz IHNlcnZpY2UgaW5zZW5zaXRpdmUuPGJyPg0KPGJyPg0KJmd0Ozxicj4NCjxicj4NCiZndDsgVGhl IGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDxicj4NCjxicj4NCiZndDsgPC9mb250PjwvdHQ+PGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2hlbi1wMnBzaXAt Y29udGVudC1zaGFyaW5nLTAwLnR4dCI+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx1Pmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNoZW4tcDJwc2lwLWNvbnRl bnQtc2hhcmluZy0wMC50eHQ8L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Ljxi cj4NCjxicj4NCjxicj4NCiZndDsgJm5ic3A7Q29tbWVudHMgYXJlIHdlbGNvbWUuPGJyPg0KPGJy Pg0KJmd0Ozxicj4NCjxicj4NCiZndDs8YnI+DQo8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQo8YnI+ DQomZ3Q7IEppb25nPGJyPg0KPGJyPg0KJmd0Ozxicj4NCjxicj4NCiZndDs8YnI+DQo8YnI+DQom Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KPGJyPg0KJmd0OzwvZm9udD48L3R0Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgPC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5m b3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1h dGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZu YnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZu YnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24m bmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJz cDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJz cDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7 dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlz Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWls Jm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgm bmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVk Jm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJz cDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2 ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZu YnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZu YnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQm bmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZu YnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5 c3RlbS4NCjwvcHJlPg== --=_alternative 0022F9C5482575F6_=-- From melodysong@huawei.com Fri Jul 17 01:49:54 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C94F3A6CF4 for ; Fri, 17 Jul 2009 01:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.33 X-Spam-Level: *** X-Spam-Status: No, score=3.33 tagged_above=-999 required=5 tests=[AWL=-3.967, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3Il8ax5TjSS for ; Fri, 17 Jul 2009 01:49:52 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 07DAB3A6D30 for ; Fri, 17 Jul 2009 01:49:52 -0700 (PDT) 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 <0KMX0047X4JZCO@szxga01-in.huawei.com> for p2psip@ietf.org; Fri, 17 Jul 2009 16:50:23 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMX00FC04JZUE@szxga01-in.huawei.com> for p2psip@ietf.org; Fri, 17 Jul 2009 16:50:23 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMX008GL4JYI5@szxml06-in.huawei.com> for p2psip@ietf.org; Fri, 17 Jul 2009 16:50:23 +0800 (CST) Date: Fri, 17 Jul 2009 16:50:22 +0800 From: Song Haibin In-reply-to: To: shen.jiong@zte.com.cn, 'Tao Ma' Message-id: <005f01ca06bb$9ec78f90$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_FpjX1AsrI4HCx69T/lw+7g)" Thread-index: AcoGrLcg4VEK4CtRRfmYauhMKw4SIgADXuNQ Cc: p2psip@ietf.org, standardMINE@googlegroups.com Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBOZXcgZHJhZnQgb24gY29udGVudCBz?= =?gb2312?b?aGFyaW5nIHVzYWdlIGZvciBSRUxPQUQ=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 08:49:54 -0000 This is a multi-part message in MIME format. --Boundary_(ID_FpjX1AsrI4HCx69T/lw+7g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi all, =20 I'm quite confused that if a peer or client wants to share its local = content of huge size, why not store the data location information to the overlay instead of the data itself?=20 =20 =20 Thanks! Haibin =20 =20 _____ =20 From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of shen.jiong@zte.com.cn Sent: Friday, July 17, 2009 2:21 PM To: Tao Ma Cc: p2psip@ietf.org; standardMINE@googlegroups.com Subject: [P2PSIP] =B4=F0=B8=B4: Re: New draft on content sharing usage = for RELOAD Hi Tao,=20 Based on the peculiarity of the content sharing usage, the content = normally is huge. So need consider of load banlance arithmetic, topology = optimize and the rules for slice very huge content to segments.=20 Thanks,=20 Jiong=20 Tao Ma =20 2009-07-16 14:37=20 =CA=D5=BC=FE=C8=CB shen.jiong@zte.com.cn, p2psip@ietf.org=20 =B3=AD=CB=CD lilichun , zhangch@bupt.edu.cn, standardMINE@googlegroups.com=20 =D6=F7=CC=E2 Re: [P2PSIP] New draft on content sharing usage for RELOAD =09 Hi,=20 As [draft-ietf-p2psip-base-03] said: =A1=B0RELOAD is designed to = support a variety of applications, including P2P multimedia communications with = the Session Initiation Protocol [I-D.ietf-p2psip-sip]. RELOAD allows the definition of new application usages. =A1=B1 I think this draft has = given an example following this guideline. There is still one important issue to = be badly noticed and discussed:=20 For RELOAD is =A1=B0designed specifically to meet the requirements for a = P2P protocol to support SIP=A1=B1 [draft-ietf-p2psip-base-03], it is applied = to support content sharing in this draft, are there some specific = requirements for content sharing usage that are too different from the SIP usage for RELOAD to support ? Or if you would make some extensions, which part = needs extension and to what extent?=20 I think this question would be general for all the P2P application = usage which is inclined to use RELOAD. It is necessary to clarify the specific requirements, especially those are not supported well by current RELOAD. = Regards=20 Tao Ma=20 16th, July, 2009=20 Mobile Life New Media Lab, Beijing University of Posts and Telecommunications=20 On Wed, Jul 1, 2009 at 9:16 AM, zte.com.cn> wrote: > > Hi all, > > We have submitted a draft on content sharing usage for RELOAD. It provides > the functionality of distributing and fetching shared content = efficiently to > and from a P2P overlay network, which performs as Content Delivery Network > and is service insensitive. > > The draft can be found at > = http://www.ietf.org/internet-drafts/draft-shen-p2psip-content-sharing-00.= txt. > Comments are welcome. > > > Thanks, > Jiong > > > -------------------------------------------------------- >=20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy = and are not permitted to disclose the contents of this communication to = others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Boundary_(ID_FpjX1AsrI4HCx69T/lw+7g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi=20 all,
 
I'm quite=20 confused that if a peer or client wants to share its local content of = huge size,=20 why not store the data location information to the = overlay=20 instead of the data itself?
 
 
Thanks!
Haibin

 
 

From: p2psip-bounces@ietf.org=20 [mailto:p2psip-bounces@ietf.org] On Behalf Of=20 shen.jiong@zte.com.cn
Sent: Friday, July 17, 2009 2:21=20 PM
To: Tao Ma
Cc: p2psip@ietf.org;=20 standardMINE@googlegroups.com
Subject: [P2PSIP] = =B4=F0=B8=B4: Re: New draft on=20 content sharing usage for RELOAD


Hi Tao, =

Based on the peculiarity of the content sharing usage, the = content=20 normally is huge. So need consider of  load banlance arithmetic, = topology=20 optimize and the rules for slice very huge content to segments. =

Thanks,
Jiong=20




Tao Ma=20 <abcdmatao@gmail.com>

2009-07-16 14:37

=CA=D5=BC=FE=C8=CB
shen.jiong@zte.com.cn,=20 p2psip@ietf.org=20
=B3=AD=CB=CD
lilichun=20 <lilichun@gmail.com>, zhangch@bupt.edu.cn,=20 standardMINE@googlegroups.com=20
=D6=F7=CC=E2
Re: [P2PSIP] New draft = on content=20 sharing usage for RELOAD

=




Hi,=20

  As = [draft-ietf-p2psip-base-03] said:=20 =A1=B0RELOAD is designed to support a variety of applications, = including P2P=20 multimedia communications with the Session Initiation Protocol=20 [I-D.ietf-p2psip-sip]. RELOAD allows the definition of new application = usages.=20 =A1=B1 I think this draft has given an example following this = guideline. There is=20 still one important issue to be badly noticed and discussed:=20

For RELOAD is =A1=B0designed = specifically to meet=20 the requirements for a P2P protocol to support SIP=A1=B1=20 [draft-ietf-p2psip-base-03], it is applied to support content sharing = in this=20 draft, are there some specific requirements for content sharing usage = that are=20 too different from the SIP usage for RELOAD to support ? Or if you = would make=20 some extensions, which part needs extension and to what extent? =

  I think this question would = be general=20 for all the P2P application usage which is inclined to use RELOAD. It = is=20 necessary to clarify the specific requirements, especially those are = not=20 supported well by current RELOAD.

   Regards=20

Tao Ma=20

16th, July, 2009=20

Mobile Life New Media Lab, Beijing = University=20 of Posts and Telecommunications=20

On Wed, Jul 1, 2009 at 9:16 AM, <shen.jiong = at=20 zte.com.cn>=20 wrote:


>

> Hi all,

>

> We = have=20 submitted a draft on content sharing usage for RELOAD.=20 It
provides

> the functionality of distributing and = fetching=20 shared content efficiently
to


> and from a P2P = overlay=20 network, which performs as Content Delivery
Network

> and = is=20 service insensitive.

>

> The draft can be found=20 at

> http://www.ietf.org/internet-drafts/draft-shen-p2psip-content= -sharing-00.txt.


>  Comments are=20 welcome.

>

>

> Thanks,

>=20 Jiong

>

>

>=20 = --------------------------------------------------------

>=20
  = 

-----------------------------------------------------=
---
ZTE Information Security Notice: The information=
 contained in this mail is solely prop=
erty of the sender's organization. This mai=
l communication is confidential. Recipients name=
d above are obligated to maintain secrecy&n=
bsp;and are not permitted to disclose the&n=
bsp;contents of this communication to others.
This email and any files transmitted with&n=
bsp;it are confidential and intended solely =
;for the use of the individual or enti=
ty to whom they are addressed. If you&=
nbsp;have received this email in error plea=
se notify the originator of the message.&nb=
sp;Any views expressed in this message are&=
nbsp;those of the individual sender.
This message has been scanned for viruses&n=
bsp;and Spam by ZTE Anti-Spam system.
--Boundary_(ID_FpjX1AsrI4HCx69T/lw+7g)-- From bbl@lowekamp.net Fri Jul 17 07:10:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D023A6849 for ; Fri, 17 Jul 2009 07:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1vQaK5Juciq for ; Fri, 17 Jul 2009 07:10:46 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 0A5103A6818 for ; Fri, 17 Jul 2009 07:10:45 -0700 (PDT) Received: by bwz28 with SMTP id 28so758971bwz.37 for ; Fri, 17 Jul 2009 07:09:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.15 with SMTP id d15mr430940fap.105.1247839764842; Fri, 17 Jul 2009 07:09:24 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2009 10:09:24 -0400 Message-ID: From: Bruce Lowekamp To: p2psip Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [P2PSIP] clients in reload and Update X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 14:10:47 -0000 On Thu, Jul 16, 2009 at 10:46 PM, Bruce Lowekamp wrote: > 1) rely on the clients to periodically Ping or Route_Query to ensure > they are connected to the correct peer. =C2=A0Unfortunately, this leaves = an > obvious gap before the topology change is noticed. =C2=A0Unlike > sip-outbound, we don't have redundant connections to compensate for > temporary loss of reachability. > > 2) define a new method for this purpose that is generic, so > independent of overlay algorithm > > 3) retain the current use of Update, and specify that a client > receiving an Update that it cannot process (because it does not speak > the overlay algorithm) SHOULD perform a Route_Query to confirm it is > still connected to the proper peer. I should have been more clear that options 2 and 3 are peer-initiated (so 2 would be a new Request a peer sends to all members of its connection table when its responsible ID range changes). Bruce From peng.yonglin@zte.com.cn Fri Jul 17 20:00:37 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6633A6E42; Fri, 17 Jul 2009 20:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.19 X-Spam-Level: X-Spam-Status: No, score=-90.19 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3y1IMZb66fx; Fri, 17 Jul 2009 20:00:35 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 82F283A6B5A; Fri, 17 Jul 2009 20:00:31 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111643559614510; Sat, 18 Jul 2009 10:43:30 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 85804.8025238956; Sat, 18 Jul 2009 10:53:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6I2SDK3026171; Sat, 18 Jul 2009 10:28:13 +0800 (CST) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: <005f01ca06bb$9ec78f90$0f0ca40a@china.huawei.com> To: Song Haibin MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Sat, 18 Jul 2009 10:28:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-18 10:28:10, Serialize complete at 2009-07-18 10:28:10 Content-Type: multipart/alternative; boundary="=_alternative 000DB620482575F7_=" X-MAIL: mse2.zte.com.cn n6I2SDK3026171 Cc: 'Tao Ma' , standardMINE@googlegroups.com, p2psip@ietf.org, p2psip-bounces@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6IAm08Li0OiBSZTogIE5ldyBkcmFmdCBv?= =?gb2312?b?biBjb250ZW50IHNoYXJpbmcgdXNhZ2UgZm9yIFJFTE9BRA==?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 03:00:37 -0000 This is a multipart message in MIME format. --=_alternative 000DB620482575F7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIA0KDQpJIHRoaW5rIHRoYXQgc3RvcmluZyBkYXRhIGFuZCBzdG9yaW5nIGRhdGEgbG9jYXRp b24gaW5mb3JtYXRpb24gdG8gb3ZlcmxheSANCmFyZSB0d28gZGlmZmVyZW50IHVzYWdlcywgYW5k IGFsbCBvZiB0aGVtIGFyZSB1c2VmdWwuIFN0b3JpbmcgZGF0YSB0byANCm92ZXJsYXkgbWF5IGlt cHJvdmUgb3RoZXIgdXNlcnMncyBkb3dubG9hZCBzcGVlZCwgYW5kIHJlZHVjZSBjb250ZW50IA0K cHJvdmlkZXJzJ3MgbG9hZC4gDQoNCnRoYW5rcyENCllvbmdsaW4NCg0KDQoNCg0KDQpTb25nIEhh aWJpbiA8bWVsb2R5c29uZ0BodWF3ZWkuY29tPiANCreivP7IyzogIHAycHNpcC1ib3VuY2VzQGll dGYub3JnDQoyMDA5LTA3LTE3IDE2OjUwDQoNCsrVvP7Iyw0Kc2hlbi5qaW9uZ0B6dGUuY29tLmNu LCAnVGFvIE1hJyA8YWJjZG1hdGFvQGdtYWlsLmNvbT4NCrOty80NCnAycHNpcEBpZXRmLm9yZywg c3RhbmRhcmRNSU5FQGdvb2dsZWdyb3Vwcy5jb20NCtb3zOINClJlOiBbUDJQU0lQXSAgICC08Li0 OiBSZTogIE5ldyBkcmFmdCBvbiBjb250ZW50IHNoYXJpbmcgdXNhZ2UgZm9yIFJFTE9BRA0KDQoN Cg0KDQoNCg0KSGkgYWxsLA0KIA0KSSdtIHF1aXRlIGNvbmZ1c2VkIHRoYXQgaWYgYSBwZWVyIG9y IGNsaWVudCB3YW50cyB0byBzaGFyZSBpdHMgbG9jYWwgDQpjb250ZW50IG9mIGh1Z2Ugc2l6ZSwg d2h5IG5vdCBzdG9yZSB0aGUgZGF0YSBsb2NhdGlvbiBpbmZvcm1hdGlvbiB0byB0aGUgDQpvdmVy bGF5IGluc3RlYWQgb2YgdGhlIGRhdGEgaXRzZWxmPyANCiANCiANClRoYW5rcyENCkhhaWJpbg0K DQogIA0KIA0KDQpGcm9tOiBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnAycHNpcC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQpPZiBzaGVuLmppb25nQHp0ZS5jb20uY24NClNl bnQ6IEZyaWRheSwgSnVseSAxNywgMjAwOSAyOjIxIFBNDQpUbzogVGFvIE1hDQpDYzogcDJwc2lw QGlldGYub3JnOyBzdGFuZGFyZE1JTkVAZ29vZ2xlZ3JvdXBzLmNvbQ0KU3ViamVjdDogW1AyUFNJ UF0gtPC4tDogUmU6IE5ldyBkcmFmdCBvbiBjb250ZW50IHNoYXJpbmcgdXNhZ2UgZm9yIFJFTE9B RA0KDQoNCkhpIFRhbywgDQoNCkJhc2VkIG9uIHRoZSBwZWN1bGlhcml0eSBvZiB0aGUgY29udGVu dCBzaGFyaW5nIHVzYWdlLCB0aGUgY29udGVudCANCm5vcm1hbGx5IGlzIGh1Z2UuIFNvIG5lZWQg Y29uc2lkZXIgb2YgIGxvYWQgYmFubGFuY2UgYXJpdGhtZXRpYywgdG9wb2xvZ3kgDQpvcHRpbWl6 ZSBhbmQgdGhlIHJ1bGVzIGZvciBzbGljZSB2ZXJ5IGh1Z2UgY29udGVudCB0byBzZWdtZW50cy4g DQoNCg0KVGhhbmtzLCANCkppb25nIA0KDQoNCg0KDQpUYW8gTWEgPGFiY2RtYXRhb0BnbWFpbC5j b20+IA0KMjAwOS0wNy0xNiAxNDozNyANCg0KDQrK1bz+yMsNCnNoZW4uamlvbmdAenRlLmNvbS5j biwgcDJwc2lwQGlldGYub3JnIA0Ks63LzQ0KbGlsaWNodW4gPGxpbGljaHVuQGdtYWlsLmNvbT4s IHpoYW5nY2hAYnVwdC5lZHUuY24sIA0Kc3RhbmRhcmRNSU5FQGdvb2dsZWdyb3Vwcy5jb20gDQrW 98ziDQpSZTogW1AyUFNJUF0gTmV3IGRyYWZ0IG9uIGNvbnRlbnQgc2hhcmluZyB1c2FnZSBmb3Ig UkVMT0FEDQoNCg0KDQoNCg0KDQoNCg0KSGksIA0KICBBcyBbZHJhZnQtaWV0Zi1wMnBzaXAtYmFz ZS0wM10gc2FpZDogobBSRUxPQUQgaXMgZGVzaWduZWQgdG8gc3VwcG9ydCBhIA0KdmFyaWV0eSBv ZiBhcHBsaWNhdGlvbnMsIGluY2x1ZGluZyBQMlAgbXVsdGltZWRpYSBjb21tdW5pY2F0aW9ucyB3 aXRoIHRoZSANClNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCBbSS1ELmlldGYtcDJwc2lwLXNp cF0uIFJFTE9BRCBhbGxvd3MgdGhlIA0KZGVmaW5pdGlvbiBvZiBuZXcgYXBwbGljYXRpb24gdXNh Z2VzLiChsSBJIHRoaW5rIHRoaXMgZHJhZnQgaGFzIGdpdmVuIGFuIA0KZXhhbXBsZSBmb2xsb3dp bmcgdGhpcyBndWlkZWxpbmUuIFRoZXJlIGlzIHN0aWxsIG9uZSBpbXBvcnRhbnQgaXNzdWUgdG8g YmUgDQpiYWRseSBub3RpY2VkIGFuZCBkaXNjdXNzZWQ6IA0KRm9yIFJFTE9BRCBpcyChsGRlc2ln bmVkIHNwZWNpZmljYWxseSB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgZm9yIGEgUDJQIA0KcHJv dG9jb2wgdG8gc3VwcG9ydCBTSVChsSBbZHJhZnQtaWV0Zi1wMnBzaXAtYmFzZS0wM10sIGl0IGlz IGFwcGxpZWQgdG8gDQpzdXBwb3J0IGNvbnRlbnQgc2hhcmluZyBpbiB0aGlzIGRyYWZ0LCBhcmUg dGhlcmUgc29tZSBzcGVjaWZpYyANCnJlcXVpcmVtZW50cyBmb3IgY29udGVudCBzaGFyaW5nIHVz YWdlIHRoYXQgYXJlIHRvbyBkaWZmZXJlbnQgZnJvbSB0aGUgU0lQIA0KdXNhZ2UgZm9yIFJFTE9B RCB0byBzdXBwb3J0ID8gT3IgaWYgeW91IHdvdWxkIG1ha2Ugc29tZSBleHRlbnNpb25zLCB3aGlj aCANCnBhcnQgbmVlZHMgZXh0ZW5zaW9uIGFuZCB0byB3aGF0IGV4dGVudD8gDQogIEkgdGhpbmsg dGhpcyBxdWVzdGlvbiB3b3VsZCBiZSBnZW5lcmFsIGZvciBhbGwgdGhlIFAyUCBhcHBsaWNhdGlv biB1c2FnZSANCndoaWNoIGlzIGluY2xpbmVkIHRvIHVzZSBSRUxPQUQuIEl0IGlzIG5lY2Vzc2Fy eSB0byBjbGFyaWZ5IHRoZSBzcGVjaWZpYyANCnJlcXVpcmVtZW50cywgZXNwZWNpYWxseSB0aG9z ZSBhcmUgbm90IHN1cHBvcnRlZCB3ZWxsIGJ5IGN1cnJlbnQgUkVMT0FELiANCiAgIFJlZ2FyZHMg DQpUYW8gTWEgDQoxNnRoLCBKdWx5LCAyMDA5IA0KTW9iaWxlIExpZmUgTmV3IE1lZGlhIExhYiwg QmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCANClRlbGVjb21tdW5pY2F0aW9ucyANCk9u IFdlZCwgSnVsIDEsIDIwMDkgYXQgOToxNiBBTSwgPHNoZW4uamlvbmcgYXQgenRlLmNvbS5jbj4g d3JvdGU6DQoNCg0KPg0KDQo+IEhpIGFsbCwNCg0KPg0KDQo+IFdlIGhhdmUgc3VibWl0dGVkIGEg ZHJhZnQgb24gY29udGVudCBzaGFyaW5nIHVzYWdlIGZvciBSRUxPQUQuIEl0DQpwcm92aWRlcw0K DQo+IHRoZSBmdW5jdGlvbmFsaXR5IG9mIGRpc3RyaWJ1dGluZyBhbmQgZmV0Y2hpbmcgc2hhcmVk IGNvbnRlbnQgDQplZmZpY2llbnRseQ0KdG8NCg0KDQo+IGFuZCBmcm9tIGEgUDJQIG92ZXJsYXkg bmV0d29yaywgd2hpY2ggcGVyZm9ybXMgYXMgQ29udGVudCBEZWxpdmVyeQ0KTmV0d29yaw0KDQo+ IGFuZCBpcyBzZXJ2aWNlIGluc2Vuc2l0aXZlLg0KDQo+DQoNCj4gVGhlIGRyYWZ0IGNhbiBiZSBm b3VuZCBhdA0KDQo+IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt c2hlbi1wMnBzaXAtY29udGVudC1zaGFyaW5nLTAwLnR4dA0KLg0KDQoNCj4gIENvbW1lbnRzIGFy ZSB3ZWxjb21lLg0KDQo+DQoNCj4NCg0KPiBUaGFua3MsDQoNCj4gSmlvbmcNCg0KPg0KDQo+DQoN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KPiANCiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRo ZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeSBhbmQgDQphcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVu dHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55 IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQg DQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkg dmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZp ZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClAyUFNJUCBtYWlsaW5nIGxpc3QNClAyUFNJUEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLg0K --=_alternative 000DB620482575F7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCA8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgdGhhdCBzdG9yaW5nIGRh dGEgYW5kIHN0b3JpbmcNCmRhdGEgbG9jYXRpb24gaW5mb3JtYXRpb24gdG8gb3ZlcmxheSBhcmUg dHdvIGRpZmZlcmVudCB1c2FnZXMsIGFuZCBhbGwNCm9mIHRoZW0gYXJlIHVzZWZ1bC4gU3Rvcmlu ZyBkYXRhIHRvIG92ZXJsYXkgbWF5IGltcHJvdmUgb3RoZXIgdXNlcnMncyBkb3dubG9hZA0Kc3Bl ZWQsIGFuZCByZWR1Y2UgY29udGVudCBwcm92aWRlcnMncyBsb2FkLiA8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoYW5rcyE8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllvbmdsaW48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk IHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+U29uZyBIYWliaW4g Jmx0O21lbG9keXNvbmdAaHVhd2VpLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7cDJwc2lwLWJvdW5jZXNAaWV0Zi5v cmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNy0xNyAx Njo1MDwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5zaGVuLmppb25nQHp0ZS5jb20uY24sICdUYW8gTWEnICZsdDthYmNkbWF0YW9AZ21haWwu Y29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+cDJwc2lwQGlldGYub3JnLCBzdGFuZGFyZE1JTkVA Z29vZ2xlZ3JvdXBzLmNvbTwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQMlBTSVBdICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO7TwuLQ6DQpSZTogJm5ic3A7TmV3IGRyYWZ0IG9uIGNvbnRlbnQg c2hhcmluZyB1c2FnZSBmb3IgUkVMT0FEPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSdtIHF1aXRlIGNvbmZ1c2VkIHRoYXQgaWYgYSBw ZWVyIG9yDQpjbGllbnQgd2FudHMgdG8gc2hhcmUgaXRzIGxvY2FsIGNvbnRlbnQgb2YgaHVnZSBz aXplLCB3aHkgbm90IHN0b3JlIHRoZQ0KZGF0YSBsb2NhdGlvbiBpbmZvcm1hdGlvbiB0byB0aGUg b3ZlcmxheSBpbnN0ZWFkIG9mIHRoZSBkYXRhIGl0c2VsZj8gPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+VGhhbmtzITxicj4NCkhhaWJpbjxicj4NCjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPg0KPGhyPjxmb250IHNpemU9 MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnAycHNpcC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5zaGVuLmpp b25nQHp0ZS5jb20uY248Yj48YnI+DQpTZW50OjwvYj4gRnJpZGF5LCBKdWx5IDE3LCAyMDA5IDI6 MjEgUE08Yj48YnI+DQpUbzo8L2I+IFRhbyBNYTxiPjxicj4NCkNjOjwvYj4gcDJwc2lwQGlldGYu b3JnOyBzdGFuZGFyZE1JTkVAZ29vZ2xlZ3JvdXBzLmNvbTxiPjxicj4NClN1YmplY3Q6PC9iPiBb UDJQU0lQXSC08Li0OiBSZTogTmV3IGRyYWZ0IG9uIGNvbnRlbnQgc2hhcmluZyB1c2FnZSBmb3IN ClJFTE9BRDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KSGkgVGFvLDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iQXJpYWwiPjxicj4NCkJhc2VkIG9uIHRoZSBwZWN1bGlhcml0eSBvZiB0aGUgY29udGVudCBz aGFyaW5nIHVzYWdlLCB0aGUgY29udGVudCBub3JtYWxseQ0KaXMgaHVnZS4gU28gbmVlZCBjb25z aWRlciBvZiAmbmJzcDtsb2FkIGJhbmxhbmNlIGFyaXRobWV0aWMsIHRvcG9sb2d5IG9wdGltaXpl DQphbmQgdGhlIHJ1bGVzIGZvciBzbGljZSB2ZXJ5IGh1Z2UgY29udGVudCB0byBzZWdtZW50cy48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0xMDAlPjwvdGFibGU+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpUaGFua3MsPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJy Pg0KSmlvbmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTI3JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+VGFvIE1h ICZsdDthYmNkbWF0YW9AZ21haWwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA3LTE2IDE0OjM3PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD03MiU+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTYlPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0K PHRkIHdpZHRoPTkzJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+c2hlbi5qaW9uZ0B6 dGUuY29tLmNuLCBwMnBzaXBAaWV0Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5saWxpY2h1biAmbHQ7bGlsaWNodW5AZ21haWwu Y29tJmd0OywNCnpoYW5nY2hAYnVwdC5lZHUuY24sIHN0YW5kYXJkTUlORUBnb29nbGVncm91cHMu Y29tPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+UmU6IFtQMlBTSVBdIE5ldyBkcmFmdCBvbiBjb250ZW50IHNoYXJpbmcNCnVzYWdlIGZv ciBSRUxPQUQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxi cj4NCjxicj4NCkhpLCA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7IEFzIFtkcmFmdC1pZXRmLXAycHNpcC1iYXNlLTAzXQ0Kc2FpZDogobBSRUxPQUQgaXMg ZGVzaWduZWQgdG8gc3VwcG9ydCBhIHZhcmlldHkgb2YgYXBwbGljYXRpb25zLCBpbmNsdWRpbmcN ClAyUCBtdWx0aW1lZGlhIGNvbW11bmljYXRpb25zIHdpdGggdGhlIFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbCBbSS1ELmlldGYtcDJwc2lwLXNpcF0uDQpSRUxPQUQgYWxsb3dzIHRoZSBkZWZp bml0aW9uIG9mIG5ldyBhcHBsaWNhdGlvbiB1c2FnZXMuIKGxIEkgdGhpbmsgdGhpcw0KZHJhZnQg aGFzIGdpdmVuIGFuIGV4YW1wbGUgZm9sbG93aW5nIHRoaXMgZ3VpZGVsaW5lLiBUaGVyZSBpcyBz dGlsbCBvbmUNCmltcG9ydGFudCBpc3N1ZSB0byBiZSBiYWRseSBub3RpY2VkIGFuZCBkaXNjdXNz ZWQ6IDwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5Gb3IgUkVMT0FE IGlzIKGwZGVzaWduZWQgc3BlY2lmaWNhbGx5DQp0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgZm9y IGEgUDJQIHByb3RvY29sIHRvIHN1cHBvcnQgU0lQobEgW2RyYWZ0LWlldGYtcDJwc2lwLWJhc2Ut MDNdLA0KaXQgaXMgYXBwbGllZCB0byBzdXBwb3J0IGNvbnRlbnQgc2hhcmluZyBpbiB0aGlzIGRy YWZ0LCBhcmUgdGhlcmUgc29tZQ0Kc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGZvciBjb250ZW50IHNo YXJpbmcgdXNhZ2UgdGhhdCBhcmUgdG9vIGRpZmZlcmVudA0KZnJvbSB0aGUgU0lQIHVzYWdlIGZv ciBSRUxPQUQgdG8gc3VwcG9ydCA/IE9yIGlmIHlvdSB3b3VsZCBtYWtlIHNvbWUgZXh0ZW5zaW9u cywNCndoaWNoIHBhcnQgbmVlZHMgZXh0ZW5zaW9uIGFuZCB0byB3aGF0IGV4dGVudD8gPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJIHRoaW5rIHRoaXMg cXVlc3Rpb24gd291bGQgYmUNCmdlbmVyYWwgZm9yIGFsbCB0aGUgUDJQIGFwcGxpY2F0aW9uIHVz YWdlIHdoaWNoIGlzIGluY2xpbmVkIHRvIHVzZSBSRUxPQUQuDQpJdCBpcyBuZWNlc3NhcnkgdG8g Y2xhcmlmeSB0aGUgc3BlY2lmaWMgcmVxdWlyZW1lbnRzLCBlc3BlY2lhbGx5IHRob3NlDQphcmUg bm90IHN1cHBvcnRlZCB3ZWxsIGJ5IGN1cnJlbnQgUkVMT0FELiA8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1JlZ2FyZHMgPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRhbyBNYSA8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+MTZ0aCwgSnVseSwgMjAwOSA8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+TW9iaWxlIExpZmUgTmV3IE1lZGlhIExhYiwgQmVp amluZyBVbml2ZXJzaXR5DQpvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zIDwvZm9udD4N CjxwPjxmb250IHNpemU9Mj48dHQ+T24gV2VkLCBKdWwgMSwgMjAwOSBhdCA5OjE2IEFNLCAmbHQ7 c2hlbi5qaW9uZyBhdCA8L3R0PjwvZm9udD48YSBocmVmPWh0dHA6Ly96dGUuY29tLmNuLz48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+PHU+enRlLmNvbS5jbjwvdT48L3R0PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7DQp3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7PGJyPg0K PGJyPg0KJmd0OyBIaSBhbGwsPGJyPg0KPGJyPg0KJmd0Ozxicj4NCjxicj4NCiZndDsgV2UgaGF2 ZSBzdWJtaXR0ZWQgYSBkcmFmdCBvbiBjb250ZW50IHNoYXJpbmcgdXNhZ2UgZm9yIFJFTE9BRC4g SXQ8YnI+DQpwcm92aWRlczxicj4NCjxicj4NCiZndDsgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgZGlz dHJpYnV0aW5nIGFuZCBmZXRjaGluZyBzaGFyZWQgY29udGVudCBlZmZpY2llbnRseTxicj4NCnRv PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBhbmQgZnJvbSBhIFAyUCBvdmVybGF5IG5ldHdvcmssIHdo aWNoIHBlcmZvcm1zIGFzIENvbnRlbnQgRGVsaXZlcnk8YnI+DQpOZXR3b3JrPGJyPg0KPGJyPg0K Jmd0OyBhbmQgaXMgc2VydmljZSBpbnNlbnNpdGl2ZS48YnI+DQo8YnI+DQomZ3Q7PGJyPg0KPGJy Pg0KJmd0OyBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0PGJyPg0KPGJyPg0KJmd0OyA8L3R0Pjwv Zm9udD48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1z aGVuLXAycHNpcC1jb250ZW50LXNoYXJpbmctMDAudHh0Ij48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZT48dHQ+PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2hlbi1w MnBzaXAtY29udGVudC1zaGFyaW5nLTAwLnR4dDwvdT48L3R0PjwvZm9udD48L2E+PGZvbnQgc2l6 ZT0yPjx0dD4uPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyAmbmJzcDtDb21tZW50cyBhcmUgd2VsY29t ZS48YnI+DQo8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KJmd0Ozxicj4NCjxicj4NCiZndDsgVGhhbmtz LDxicj4NCjxicj4NCiZndDsgSmlvbmc8YnI+DQo8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KJmd0Ozxi cj4NCjxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQomZ3Q7PC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiA8YnI+DQogJm5ic3A7PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNp emU9Mz48dHQ+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRl bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz ZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9m IHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBm aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkDQpz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhl eSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpz ZW5kZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5k IFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPGJyPg0KPC90dD48L2ZvbnQ+PGZvbnQgc2l6 ZT0yPjx0dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NClAyUFNJUCBtYWlsaW5nIGxpc3Q8YnI+DQpQMlBTSVBAaWV0Zi5vcmc8YnI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcDxicj4NCjwvdHQ+PC9mb250Pg0K PGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNw O05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlz Jm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4m bmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGln YXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZu YnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3Rv Jm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7Zmls ZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZp ZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJz cDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVz c2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZu YnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNw O3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7 QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNz YWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtz Y2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZu YnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 000DB620482575F7_=-- From julian@orchidseed.org Sun Jul 19 12:13:34 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8E63A68A7 for ; Sun, 19 Jul 2009 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Wg5Jefayyo0 for ; Sun, 19 Jul 2009 12:13:33 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 5C9653A67AC for ; Sun, 19 Jul 2009 12:13:32 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so459473rvb.49 for ; Sun, 19 Jul 2009 12:13:20 -0700 (PDT) Received: by 10.140.225.10 with SMTP id x10mr1927372rvg.65.1248030800013; Sun, 19 Jul 2009 12:13:20 -0700 (PDT) Received: from ?10.0.1.2? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id k2sm4244359rvb.22.2009.07.19.12.13.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 19 Jul 2009 12:13:18 -0700 (PDT) Message-Id: From: jc To: p2psip@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-1--859343498 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 19 Jul 2009 12:13:16 -0700 X-Mailer: Apple Mail (2.935.3) Subject: [P2PSIP] Two Credential-Server Elements Described X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 19:13:34 -0000 --Apple-Mail-1--859343498 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit There are two credential-server elements, which one is correct? credential-server This element contains the URL at which the credential server can be reached in a "url" element. This URL MUST be of type "https:". More than one credential-server element may be present. credential-server Base URL for credential server. jc --Apple-Mail-1--859343498 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit There are two credential-server elements, which one is correct?

credential-server   This element contains the URL at which the
      credential server can be reached in a "url" element.  This URL
      MUST be of type "https:".  More than one credential-server element
      may be present.

credential-server  Base URL for credential server.

jc
--Apple-Mail-1--859343498-- From wang.jun17@zte.com.cn Sun Jul 19 22:05:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F8B3A67B6; Sun, 19 Jul 2009 22:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.99 X-Spam-Level: X-Spam-Status: No, score=-88.99 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE-3O57NJeJZ; Sun, 19 Jul 2009 22:05:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 20C653A67B8; Sun, 19 Jul 2009 22:05:46 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111643559614510; Mon, 20 Jul 2009 12:47:58 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 46629.8025238956; Mon, 20 Jul 2009 12:57:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6K53iVt064241; Mon, 20 Jul 2009 13:03:44 +0800 (CST) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: <005f01ca06bb$9ec78f90$0f0ca40a@china.huawei.com> To: Song Haibin MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Mon, 20 Jul 2009 13:03:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-20 13:03:37, Serialize complete at 2009-07-20 13:03:37 Content-Type: multipart/alternative; boundary="=_alternative 001BCBDE482575F9_=" X-MAIL: mse2.zte.com.cn n6K53iVt064241 Cc: 'Tao Ma' , standardMINE@googlegroups.com, p2psip@ietf.org, p2psip-bounces@ietf.org Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBOZXcgZHJhZnQgb24gY29udGVudCBz?= =?gb2312?b?aGFyaW5nIHVzYWdlIGZvciBSRUxPQUQ=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 05:05:52 -0000 This is a multipart message in MIME format. --=_alternative 001BCBDE482575F9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 MSlJZiB0aGUgcGVlcnMgb25seSBzdG9yZSB0aGUgbG9jYXRpb24gb2YgdGhlIGRhdGEgc2VnbWVu dCwgZXZlcnkgZGF0YSANCnJlYWQvd3JpdGUgcmVxdWVzdCBtdXN0IGJlIHByb2Nlc3NlZCBhdCB0 aGUgb3JpZ2luYWwgcGVlcnMsIHRoZSANCnBlcmZvcm1hbmNlIGlzIGEgcHJvYmxlbS4NCjIpRm9y IHRoZSBwdXJwb3NlIG9mIHRyYWZmaWMgbG9jYWxpemF0aW9uLCB0aGUgY29udGVudCBpdHNlbGYg c2hvdWxkIGJlIA0KcHVzaGVkIHRvIHRoZSBwbGFjZXMgbmVhcmVzdCB0byB0aGUgdXNlci4NCjMp VGhlIHBlZXJzIGFyZSBzdWdnZXN0ZWQgdG8gYmUgZGVwbG95ZWQgYnkgdGhlIHNlcnZpY2UgcHJv dmlkZXIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KICAgIFdhbmcgSnVuKFJ1c3NlbGwgV2FuZykNCiBTeXN0ZW0gQXJjaGl0ZWN0dXJlIERl cHQuIG9mIENlbnRyZSBSJkQsWlRFIENvcnAuDQogQWRkcjogNjggWmlqaW5naHVhIFJvYWQsTmFu amluZw0KIE1vYmlsZToxMzc3MDYwNDQ1NSANCiBUZWw6ICAgMDI1LTUyODc3NjQ4IA0KIE1TTjog cnVzc2VsbHdAbWFpbC53aC5haC5jbiANCg0KDQoNCg0KDQpTb25nIEhhaWJpbiA8bWVsb2R5c29u Z0BodWF3ZWkuY29tPiANCreivP7IyzogIHAycHNpcC1ib3VuY2VzQGlldGYub3JnDQoyMDA5LTA3 LTE3IDE2OjUwDQoNCsrVvP7Iyw0Kc2hlbi5qaW9uZ0B6dGUuY29tLmNuLCAnVGFvIE1hJyA8YWJj ZG1hdGFvQGdtYWlsLmNvbT4NCrOty80NCnAycHNpcEBpZXRmLm9yZywgc3RhbmRhcmRNSU5FQGdv b2dsZWdyb3Vwcy5jb20NCtb3zOINClJlOiBbUDJQU0lQXSAgICC08Li0OiBSZTogIE5ldyBkcmFm dCBvbiBjb250ZW50IHNoYXJpbmcgdXNhZ2UgZm9yIFJFTE9BRA0KDQoNCg0KDQoNCg0KSGkgYWxs LA0KIA0KSSdtIHF1aXRlIGNvbmZ1c2VkIHRoYXQgaWYgYSBwZWVyIG9yIGNsaWVudCB3YW50cyB0 byBzaGFyZSBpdHMgbG9jYWwgDQpjb250ZW50IG9mIGh1Z2Ugc2l6ZSwgd2h5IG5vdCBzdG9yZSB0 aGUgZGF0YSBsb2NhdGlvbiBpbmZvcm1hdGlvbiB0byB0aGUgDQpvdmVybGF5IGluc3RlYWQgb2Yg dGhlIGRhdGEgaXRzZWxmPyANCiANCiANClRoYW5rcyENCkhhaWJpbg0KDQogIA0KIA0KDQpGcm9t OiBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnAycHNpcC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgDQpPZiBzaGVuLmppb25nQHp0ZS5jb20uY24NClNlbnQ6IEZyaWRheSwgSnVs eSAxNywgMjAwOSAyOjIxIFBNDQpUbzogVGFvIE1hDQpDYzogcDJwc2lwQGlldGYub3JnOyBzdGFu ZGFyZE1JTkVAZ29vZ2xlZ3JvdXBzLmNvbQ0KU3ViamVjdDogW1AyUFNJUF0gtPC4tDogUmU6IE5l dyBkcmFmdCBvbiBjb250ZW50IHNoYXJpbmcgdXNhZ2UgZm9yIFJFTE9BRA0KDQoNCkhpIFRhbywg DQoNCkJhc2VkIG9uIHRoZSBwZWN1bGlhcml0eSBvZiB0aGUgY29udGVudCBzaGFyaW5nIHVzYWdl LCB0aGUgY29udGVudCANCm5vcm1hbGx5IGlzIGh1Z2UuIFNvIG5lZWQgY29uc2lkZXIgb2YgIGxv YWQgYmFubGFuY2UgYXJpdGhtZXRpYywgdG9wb2xvZ3kgDQpvcHRpbWl6ZSBhbmQgdGhlIHJ1bGVz IGZvciBzbGljZSB2ZXJ5IGh1Z2UgY29udGVudCB0byBzZWdtZW50cy4gDQoNCg0KVGhhbmtzLCAN Ckppb25nIA0KDQoNCg0KDQpUYW8gTWEgPGFiY2RtYXRhb0BnbWFpbC5jb20+IA0KMjAwOS0wNy0x NiAxNDozNyANCg0KDQrK1bz+yMsNCnNoZW4uamlvbmdAenRlLmNvbS5jbiwgcDJwc2lwQGlldGYu b3JnIA0Ks63LzQ0KbGlsaWNodW4gPGxpbGljaHVuQGdtYWlsLmNvbT4sIHpoYW5nY2hAYnVwdC5l ZHUuY24sIA0Kc3RhbmRhcmRNSU5FQGdvb2dsZWdyb3Vwcy5jb20gDQrW98ziDQpSZTogW1AyUFNJ UF0gTmV3IGRyYWZ0IG9uIGNvbnRlbnQgc2hhcmluZyB1c2FnZSBmb3IgUkVMT0FEDQoNCg0KDQoN Cg0KDQoNCg0KSGksIA0KICBBcyBbZHJhZnQtaWV0Zi1wMnBzaXAtYmFzZS0wM10gc2FpZDogobBS RUxPQUQgaXMgZGVzaWduZWQgdG8gc3VwcG9ydCBhIA0KdmFyaWV0eSBvZiBhcHBsaWNhdGlvbnMs IGluY2x1ZGluZyBQMlAgbXVsdGltZWRpYSBjb21tdW5pY2F0aW9ucyB3aXRoIHRoZSANClNlc3Np b24gSW5pdGlhdGlvbiBQcm90b2NvbCBbSS1ELmlldGYtcDJwc2lwLXNpcF0uIFJFTE9BRCBhbGxv d3MgdGhlIA0KZGVmaW5pdGlvbiBvZiBuZXcgYXBwbGljYXRpb24gdXNhZ2VzLiChsSBJIHRoaW5r IHRoaXMgZHJhZnQgaGFzIGdpdmVuIGFuIA0KZXhhbXBsZSBmb2xsb3dpbmcgdGhpcyBndWlkZWxp bmUuIFRoZXJlIGlzIHN0aWxsIG9uZSBpbXBvcnRhbnQgaXNzdWUgdG8gYmUgDQpiYWRseSBub3Rp Y2VkIGFuZCBkaXNjdXNzZWQ6IA0KRm9yIFJFTE9BRCBpcyChsGRlc2lnbmVkIHNwZWNpZmljYWxs eSB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgZm9yIGEgUDJQIA0KcHJvdG9jb2wgdG8gc3VwcG9y dCBTSVChsSBbZHJhZnQtaWV0Zi1wMnBzaXAtYmFzZS0wM10sIGl0IGlzIGFwcGxpZWQgdG8gDQpz dXBwb3J0IGNvbnRlbnQgc2hhcmluZyBpbiB0aGlzIGRyYWZ0LCBhcmUgdGhlcmUgc29tZSBzcGVj aWZpYyANCnJlcXVpcmVtZW50cyBmb3IgY29udGVudCBzaGFyaW5nIHVzYWdlIHRoYXQgYXJlIHRv byBkaWZmZXJlbnQgZnJvbSB0aGUgU0lQIA0KdXNhZ2UgZm9yIFJFTE9BRCB0byBzdXBwb3J0ID8g T3IgaWYgeW91IHdvdWxkIG1ha2Ugc29tZSBleHRlbnNpb25zLCB3aGljaCANCnBhcnQgbmVlZHMg ZXh0ZW5zaW9uIGFuZCB0byB3aGF0IGV4dGVudD8gDQogIEkgdGhpbmsgdGhpcyBxdWVzdGlvbiB3 b3VsZCBiZSBnZW5lcmFsIGZvciBhbGwgdGhlIFAyUCBhcHBsaWNhdGlvbiB1c2FnZSANCndoaWNo IGlzIGluY2xpbmVkIHRvIHVzZSBSRUxPQUQuIEl0IGlzIG5lY2Vzc2FyeSB0byBjbGFyaWZ5IHRo ZSBzcGVjaWZpYyANCnJlcXVpcmVtZW50cywgZXNwZWNpYWxseSB0aG9zZSBhcmUgbm90IHN1cHBv cnRlZCB3ZWxsIGJ5IGN1cnJlbnQgUkVMT0FELiANCiAgIFJlZ2FyZHMgDQpUYW8gTWEgDQoxNnRo LCBKdWx5LCAyMDA5IA0KTW9iaWxlIExpZmUgTmV3IE1lZGlhIExhYiwgQmVpamluZyBVbml2ZXJz aXR5IG9mIFBvc3RzIGFuZCANClRlbGVjb21tdW5pY2F0aW9ucyANCk9uIFdlZCwgSnVsIDEsIDIw MDkgYXQgOToxNiBBTSwgPHNoZW4uamlvbmcgYXQgenRlLmNvbS5jbj4gd3JvdGU6DQoNCg0KPg0K DQo+IEhpIGFsbCwNCg0KPg0KDQo+IFdlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgb24gY29udGVu dCBzaGFyaW5nIHVzYWdlIGZvciBSRUxPQUQuIEl0DQpwcm92aWRlcw0KDQo+IHRoZSBmdW5jdGlv bmFsaXR5IG9mIGRpc3RyaWJ1dGluZyBhbmQgZmV0Y2hpbmcgc2hhcmVkIGNvbnRlbnQgDQplZmZp Y2llbnRseQ0KdG8NCg0KDQo+IGFuZCBmcm9tIGEgUDJQIG92ZXJsYXkgbmV0d29yaywgd2hpY2gg cGVyZm9ybXMgYXMgQ29udGVudCBEZWxpdmVyeQ0KTmV0d29yaw0KDQo+IGFuZCBpcyBzZXJ2aWNl IGluc2Vuc2l0aXZlLg0KDQo+DQoNCj4gVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdA0KDQo+IA0K aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2hlbi1wMnBzaXAtY29u dGVudC1zaGFyaW5nLTAwLnR4dA0KLg0KDQoNCj4gIENvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQo+ DQoNCj4NCg0KPiBUaGFua3MsDQoNCj4gSmlvbmcNCg0KPg0KDQo+DQoNCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPiANCiANCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdh bml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg DQphcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgDQpzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVz c2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2Vk IGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBzZW5kZXIuDQpU aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUg QW50aS1TcGFtIA0Kc3lzdGVtLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClAyUFNJUCBtYWlsaW5nIGxpc3QNClAyUFNJUEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90 aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBj b25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBv ZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRo b3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 001BCBDE482575F9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEpSWYgdGhlIHBlZXJzIG9ubHkg c3RvcmUgdGhlIGxvY2F0aW9uDQpvZiB0aGUgZGF0YSBzZWdtZW50LCBldmVyeSBkYXRhIHJlYWQv d3JpdGUgcmVxdWVzdCBtdXN0IGJlIHByb2Nlc3NlZCBhdA0KdGhlIG9yaWdpbmFsIHBlZXJzLCB0 aGUgcGVyZm9ybWFuY2UgaXMgYSBwcm9ibGVtLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+MilGb3IgdGhlIHB1cnBvc2Ugb2YgdHJhZmZpYyBsb2NhbGl6YXRpb24s DQp0aGUgY29udGVudCBpdHNlbGYgc2hvdWxkIGJlIHB1c2hlZCB0byB0aGUgcGxhY2VzIG5lYXJl c3QgdG8gdGhlIHVzZXIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4zKVRoZSBwZWVycyBhcmUgc3VnZ2VzdGVkIHRvIGJlIGRlcGxveWVkDQpieSB0aGUgc2Vydmlj ZSBwcm92aWRlci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiAmbmJzcDsgJm5ic3A7V2FuZyBKdW4oUnVzc2VsbCBXYW5nKTxicj4NCiBTeXN0ZW0gQXJj aGl0ZWN0dXJlIERlcHQuIG9mIENlbnRyZSBSJmFtcDtELFpURSBDb3JwLjxicj4NCiBBZGRyOiA2 OCBaaWppbmdodWEgUm9hZCxOYW5qaW5nPGJyPg0KIE1vYmlsZToxMzc3MDYwNDQ1NSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8 YnI+DQogVGVsOiAmbmJzcDsgMDI1LTUyODc3NjQ4ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDxicj4NCiBNU046IHJ1c3NlbGx3QG1haWwu d2guYWguY24gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4NCjxicj4NCjwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Tb25nIEhhaWJp biAmbHQ7bWVsb2R5c29uZ0BodWF3ZWkuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwMnBzaXAtYm91bmNlc0BpZXRm Lm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA3LTE3 IDE2OjUwPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPnNoZW4uamlvbmdAenRlLmNvbS5jbiwgJ1RhbyBNYScgJmx0O2FiY2RtYXRhb0BnbWFp bC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5wMnBzaXBAaWV0Zi5vcmcsIHN0YW5kYXJkTUlO RUBnb29nbGVncm91cHMuY29tPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW1AyUFNJUF0gJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7tPC4tDoNClJlOiAmbmJzcDtOZXcgZHJhZnQgb24gY29udGVu dCBzaGFyaW5nIHVzYWdlIGZvciBSRUxPQUQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SGkgYWxsLDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JJ20gcXVpdGUgY29uZnVzZWQgdGhhdCBpZiBh IHBlZXIgb3INCmNsaWVudCB3YW50cyB0byBzaGFyZSBpdHMgbG9jYWwgY29udGVudCBvZiBodWdl IHNpemUsIHdoeSBub3Qgc3RvcmUgdGhlDQpkYXRhIGxvY2F0aW9uIGluZm9ybWF0aW9uIHRvIHRo ZSBvdmVybGF5IGluc3RlYWQgb2YgdGhlIGRhdGEgaXRzZWxmPyA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5UaGFua3MhPGJyPg0KSGFpYmluPGJyPg0KPGJyPg0KIDwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8aHI+PGZvbnQgc2l6 ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IHAycHNpcC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPnNoZW4u amlvbmdAenRlLmNvbS5jbjxiPjxicj4NClNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMTcsIDIwMDkg MjoyMSBQTTxiPjxicj4NClRvOjwvYj4gVGFvIE1hPGI+PGJyPg0KQ2M6PC9iPiBwMnBzaXBAaWV0 Zi5vcmc7IHN0YW5kYXJkTUlORUBnb29nbGVncm91cHMuY29tPGI+PGJyPg0KU3ViamVjdDo8L2I+ IFtQMlBTSVBdILTwuLQ6IFJlOiBOZXcgZHJhZnQgb24gY29udGVudCBzaGFyaW5nIHVzYWdlIGZv cg0KUkVMT0FEPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQpIaSBUYW8sPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJBcmlhbCI+PGJyPg0KQmFzZWQgb24gdGhlIHBlY3VsaWFyaXR5IG9mIHRoZSBjb250ZW50 IHNoYXJpbmcgdXNhZ2UsIHRoZSBjb250ZW50IG5vcm1hbGx5DQppcyBodWdlLiBTbyBuZWVkIGNv bnNpZGVyIG9mICZuYnNwO2xvYWQgYmFubGFuY2UgYXJpdGhtZXRpYywgdG9wb2xvZ3kgb3B0aW1p emUNCmFuZCB0aGUgcnVsZXMgZm9yIHNsaWNlIHZlcnkgaHVnZSBjb250ZW50IHRvIHNlZ21lbnRz LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTEwMCU+PC90YWJsZT4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NClRoYW5rcyw8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48 YnI+DQpKaW9uZzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxi cj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MjclPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5UYW8g TWEgJmx0O2FiY2RtYXRhb0BnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDctMTYgMTQ6Mzc8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTcyJT4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NiU+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+ DQo8dGQgd2lkdGg9OTMlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5zaGVuLmppb25n QHp0ZS5jb20uY24sIHAycHNpcEBpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmxpbGljaHVuICZsdDtsaWxpY2h1bkBnbWFp bC5jb20mZ3Q7LA0KemhhbmdjaEBidXB0LmVkdS5jbiwgc3RhbmRhcmRNSU5FQGdvb2dsZWdyb3Vw cy5jb208L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5SZTogW1AyUFNJUF0gTmV3IGRyYWZ0IG9uIGNvbnRlbnQgc2hhcmluZw0KdXNhZ2Ug Zm9yIFJFTE9BRDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K PGJyPg0KPGJyPg0KSGksIDwvZm9udD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgQXMgW2RyYWZ0LWlldGYtcDJwc2lwLWJhc2UtMDNdDQpzYWlkOiChsFJFTE9BRCBp cyBkZXNpZ25lZCB0byBzdXBwb3J0IGEgdmFyaWV0eSBvZiBhcHBsaWNhdGlvbnMsIGluY2x1ZGlu Zw0KUDJQIG11bHRpbWVkaWEgY29tbXVuaWNhdGlvbnMgd2l0aCB0aGUgU2Vzc2lvbiBJbml0aWF0 aW9uIFByb3RvY29sIFtJLUQuaWV0Zi1wMnBzaXAtc2lwXS4NClJFTE9BRCBhbGxvd3MgdGhlIGRl ZmluaXRpb24gb2YgbmV3IGFwcGxpY2F0aW9uIHVzYWdlcy4gobEgSSB0aGluayB0aGlzDQpkcmFm dCBoYXMgZ2l2ZW4gYW4gZXhhbXBsZSBmb2xsb3dpbmcgdGhpcyBndWlkZWxpbmUuIFRoZXJlIGlz IHN0aWxsIG9uZQ0KaW1wb3J0YW50IGlzc3VlIHRvIGJlIGJhZGx5IG5vdGljZWQgYW5kIGRpc2N1 c3NlZDogPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkZvciBSRUxP QUQgaXMgobBkZXNpZ25lZCBzcGVjaWZpY2FsbHkNCnRvIG1lZXQgdGhlIHJlcXVpcmVtZW50cyBm b3IgYSBQMlAgcHJvdG9jb2wgdG8gc3VwcG9ydCBTSVChsSBbZHJhZnQtaWV0Zi1wMnBzaXAtYmFz ZS0wM10sDQppdCBpcyBhcHBsaWVkIHRvIHN1cHBvcnQgY29udGVudCBzaGFyaW5nIGluIHRoaXMg ZHJhZnQsIGFyZSB0aGVyZSBzb21lDQpzcGVjaWZpYyByZXF1aXJlbWVudHMgZm9yIGNvbnRlbnQg c2hhcmluZyB1c2FnZSB0aGF0IGFyZSB0b28gZGlmZmVyZW50DQpmcm9tIHRoZSBTSVAgdXNhZ2Ug Zm9yIFJFTE9BRCB0byBzdXBwb3J0ID8gT3IgaWYgeW91IHdvdWxkIG1ha2Ugc29tZSBleHRlbnNp b25zLA0Kd2hpY2ggcGFydCBuZWVkcyBleHRlbnNpb24gYW5kIHRvIHdoYXQgZXh0ZW50PyA8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEkgdGhpbmsgdGhp cyBxdWVzdGlvbiB3b3VsZCBiZQ0KZ2VuZXJhbCBmb3IgYWxsIHRoZSBQMlAgYXBwbGljYXRpb24g dXNhZ2Ugd2hpY2ggaXMgaW5jbGluZWQgdG8gdXNlIFJFTE9BRC4NCkl0IGlzIG5lY2Vzc2FyeSB0 byBjbGFyaWZ5IHRoZSBzcGVjaWZpYyByZXF1aXJlbWVudHMsIGVzcGVjaWFsbHkgdGhvc2UNCmFy ZSBub3Qgc3VwcG9ydGVkIHdlbGwgYnkgY3VycmVudCBSRUxPQUQuIDwvZm9udD4NCjxwPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7UmVnYXJkcyA8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VGFvIE1hIDwvZm9udD4NCjxwPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4xNnRoLCBKdWx5LCAyMDA5IDwvZm9udD4NCjxwPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5Nb2JpbGUgTGlmZSBOZXcgTWVkaWEgTGFiLCBC ZWlqaW5nIFVuaXZlcnNpdHkNCm9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMgPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0yPjx0dD5PbiBXZWQsIEp1bCAxLCAyMDA5IGF0IDk6MTYgQU0sICZs dDtzaGVuLmppb25nIGF0IDwvdHQ+PC9mb250PjxhIGhyZWY9aHR0cDovL3p0ZS5jb20uY24vPjxm b250IHNpemU9MiBjb2xvcj1ibHVlPjx0dD48dT56dGUuY29tLmNuPC91PjwvdHQ+PC9mb250Pjwv YT48Zm9udCBzaXplPTI+PHR0PiZndDsNCndyb3RlOjxicj4NCjxicj4NCjxicj4NCiZndDs8YnI+ DQo8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQo8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KJmd0OyBXZSBo YXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IG9uIGNvbnRlbnQgc2hhcmluZyB1c2FnZSBmb3IgUkVMT0FE LiBJdDxicj4NCnByb3ZpZGVzPGJyPg0KPGJyPg0KJmd0OyB0aGUgZnVuY3Rpb25hbGl0eSBvZiBk aXN0cmlidXRpbmcgYW5kIGZldGNoaW5nIHNoYXJlZCBjb250ZW50IGVmZmljaWVudGx5PGJyPg0K dG88YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IGFuZCBmcm9tIGEgUDJQIG92ZXJsYXkgbmV0d29yaywg d2hpY2ggcGVyZm9ybXMgYXMgQ29udGVudCBEZWxpdmVyeTxicj4NCk5ldHdvcms8YnI+DQo8YnI+ DQomZ3Q7IGFuZCBpcyBzZXJ2aWNlIGluc2Vuc2l0aXZlLjxicj4NCjxicj4NCiZndDs8YnI+DQo8 YnI+DQomZ3Q7IFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ8YnI+DQo8YnI+DQomZ3Q7IDwvdHQ+ PC9mb250PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXNoZW4tcDJwc2lwLWNvbnRlbnQtc2hhcmluZy0wMC50eHQiPjxmb250IHNpemU9MiBjb2xvcj1i bHVlPjx0dD48dT5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zaGVu LXAycHNpcC1jb250ZW50LXNoYXJpbmctMDAudHh0PC91PjwvdHQ+PC9mb250PjwvYT48Zm9udCBz aXplPTI+PHR0Pi48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7ICZuYnNwO0NvbW1lbnRzIGFyZSB3ZWxj b21lLjxicj4NCjxicj4NCiZndDs8YnI+DQo8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KJmd0OyBUaGFu a3MsPGJyPg0KPGJyPg0KJmd0OyBKaW9uZzxicj4NCjxicj4NCiZndDs8YnI+DQo8YnI+DQomZ3Q7 PGJyPg0KPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCiZndDs8L3R0PjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCiAmbmJzcDs8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zPjx0dD4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhl IHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24NCmlzIGNvbmZp ZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWlu IHNlY3JlY3kNCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvDQpvdGhlcnMuPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55 IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQN CnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSBhZGRyZXNzZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YNCnRoZSBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwN CnNlbmRlci48YnI+DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48YnI+DQo8L3R0PjwvZm9udD48Zm9udCBz aXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KUDJQU0lQIG1haWxpbmcgbGlzdDxicj4NClAyUFNJUEBpZXRmLm9yZzxicj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPGJyPg0KPC90dD48L2ZvbnQ+ DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 001BCBDE482575F9_=-- From zongning@huawei.com Mon Jul 20 18:17:11 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CF43A69B7 for ; Mon, 20 Jul 2009 18:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.365 X-Spam-Level: X-Spam-Status: No, score=-99.365 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AygmfoJ1ikA0 for ; Mon, 20 Jul 2009 18:17:10 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 018B83A635F for ; Mon, 20 Jul 2009 18:17:10 -0700 (PDT) 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 <0KN30017NY7DPQ@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jul 2009 09:16:26 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN300JVDY7DTD@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jul 2009 09:16:25 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.164.12.81]) by szxmc04-in.huawei.com (mshttpd); Tue, 21 Jul 2009 09:16:25 +0800 Date: Tue, 21 Jul 2009 09:16:25 +0800 From: zongning 63316 To: p2psip@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_XSMszyGwdDfWOdElbkqbdg)" Content-language: en X-Accept-Language: en Priority: normal Subject: [P2PSIP] Welcome to join DECADE mailing list to discuss in-network storage for P2P X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 01:17:11 -0000 This is a multi-part message in MIME format. --Boundary_(ID_XSMszyGwdDfWOdElbkqbdg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Dear expert in P2PSIP, You are welcome to join the decade@ietf.org mailing list to discuss in-network storage for P2P applications. Please see the mailing list information below. BR, Ning Zong --Boundary_(ID_XSMszyGwdDfWOdElbkqbdg) Content-type: message/rfc822 Content-disposition: inline Received: from [172.24.1.24] (Forwarded-For: [10.164.12.81]) by szxmc04-in.huawei.com (mshttpd); Tue, 21 Jul 2009 09:11:39 +0800 Date: Tue, 21 Jul 2009 09:11:39 +0800 From: zongning 63316 Subject: Welcome to join DECADE mailing list to discuss in-network storage for P2P To: ppsp@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_CWQltBf3SSKRygGGpq+g+g)" Content-language: en X-Accept-Language: en Priority: normal This is a multi-part message in MIME format. --Boundary_(ID_CWQltBf3SSKRygGGpq+g+g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Dear expert in PPSP, You are welcome to join the decade@ietf.org mailing list to discuss in-network storage for P2P applications. Please see the mailing list information below. BR, Ning Zong --Boundary_(ID_CWQltBf3SSKRygGGpq+g+g) Content-type: message/rfc822 Content-disposition: inline Return-path: Received: from huawei.com ([172.24.2.12]) by szxmc04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN30056PCJH56@szxmc04-in.huawei.com> for zongning@huawei.com; Tue, 21 Jul 2009 01:28:29 +0800 (CST) Received: from szxga04-in (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 <0KN300J9PCJH4E@szxga04-in.huawei.com> for zongning@huawei.com; Tue, 21 Jul 2009 01:28:29 +0800 (CST) Received: from szxrg03-in.huawei.com ([172.24.1.40]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN3004OLCJB6Q@szxga04-in.huawei.com> for zongning@huawei.com (ORCPT zongning@huawei.com); Tue, 21 Jul 2009 01:28:29 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by szxrg03-in.huawei.com (MOS 3.10.5-GA) id DBF97740; Tue, 21 Jul 2009 01:28:29 +0800 (CST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by szxrg03-in.huawei.com (MOS 3.10.5-GA) with ESMTP id DBF97734; Tue, 21 Jul 2009 01:28:28 +0800 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B77428C22C for ; Mon, 20 Jul 2009 10:16:50 -0700 (PDT) Date: Mon, 20 Jul 2009 10:16:48 -0700 From: decade-request@ietf.org Subject: Welcome to the "decade" mailing list Sender: decade-bounces@ietf.org To: zongning@huawei.com Errors-to: decade-bounces@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk X-BeenThere: decade@ietf.org X-List-Administrivia: yes X-Junkmail-Status: score=10/50, host=szxrg03-in.huawei.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020208.4A64A93D.0161:SCFSTAT3674418,ss=1,fgs=0, ip=64.170.98.32, so=2009-03-06 19:59:02, dmn=5.7.1/2009-06-05, mode=single engine X-Junkmail-IWF: false X-Mirapoint-Loop-Id: fde27ab5255e82b859cfcfa5bfc144c2 X-Mailman-Version: 2.1.9 List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" X-No-Archive: yes Original-recipient: rfc822;@szxmc04-in.huawei.com:zongning@huawei.com Welcome to the decade@ietf.org mailing list! Dear expert, You are welcome to join the decade@ietf.org mailing list. We will discuss a possible way to move p2p applications data plane into the network and how to integrate it with p2p applications seamlessly. It will help to save the last-mile bandwidth problem caused by p2p applications. We will also discuss to use a possible simple unified protocol to access the in-network storage. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public. To post to this list, send your email to: decade@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/decade If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www.ietf.org/mailman/options/decade/zongning%40huawei.com You can also make such adjustments via email by sending a message to: decade-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: dwIqhccj Normally, Mailman will remind you of your ietf.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. --Boundary_(ID_CWQltBf3SSKRygGGpq+g+g)-- --Boundary_(ID_XSMszyGwdDfWOdElbkqbdg)-- From zongning@huawei.com Mon Jul 20 18:56:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15563A695F for ; Mon, 20 Jul 2009 18:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.171 X-Spam-Level: X-Spam-Status: No, score=-99.171 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk48mTW+x46Q for ; Mon, 20 Jul 2009 18:56:31 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F0D883A6942 for ; Mon, 20 Jul 2009 18:56:30 -0700 (PDT) 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 <0KN400DBI023ZR@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jul 2009 09:56:27 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN4005GB023YL@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jul 2009 09:56:27 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.164.12.81]) by szxmc04-in.huawei.com (mshttpd); Tue, 21 Jul 2009 09:56:27 +0800 Date: Tue, 21 Jul 2009 09:56:27 +0800 From: zongning 63316 In-reply-to: To: zongning 63316 Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: Cc: p2psip@ietf.org Subject: [P2PSIP] DECADE Mailing list infornation X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 01:56:31 -0000 I just copy the mailing list link infomation from the original mail, for your convenience. Thank you! ======================================================================== You are welcome to join the decade@ietf.org mailing list. We will discuss a possible way to move p2p applications data plane into the network and how to integrate it with p2p applications seamlessly. It will help to save the last-mile bandwidth problem caused by p2p applications. We will also discuss to use a possible simple unified protocol to access the in-network storage. To post to this list, send your email to: decade@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/decade ======================================================================= ----- Original Message ----- From: zongning 63316 Date: Tuesday, July 21, 2009 9:17 am Subject: [P2PSIP] Welcome to join DECADE mailing list to discuss in-network storage for P2P To: p2psip@ietf.org > Dear expert in P2PSIP, > > You are welcome to join the decade@ietf.org mailing list to > discuss in-network storage for P2P applications. Please see the > mailing list information below. > > BR, > Ning Zong > From melodysong@huawei.com Tue Jul 21 00:02:19 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591EC28C1BC for ; Tue, 21 Jul 2009 00:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AWL=2.259, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwVGurdJttfC for ; Tue, 21 Jul 2009 00:02:19 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 098883A6E2E for ; Tue, 21 Jul 2009 00:02:19 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN400FPNE63C8@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jul 2009 15:01:15 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN400JYEE63XW@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jul 2009 15:01:15 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN400DTUE63QC@szxml06-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jul 2009 15:01:15 +0800 (CST) Date: Tue, 21 Jul 2009 15:01:15 +0800 From: Song Haibin To: p2psip@ietf.org Message-id: <00d401ca09d1$0a05fd60$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcoJzolA0el+Orf1QxigqcR1Oi2mjgAAnjSQ Subject: [P2PSIP] FW: [decade] Poll for the time slot of DECADE bar BoF X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 07:02:19 -0000 >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of Song Haibin >Sent: Tuesday, July 21, 2009 2:43 PM >To: decade@ietf.org >Subject: [decade] Poll for the time slot of DECADE bar BoF > >Dear all, > >First, thanks to Alexey and Lisa for their help to setup this >mailing list. > >Again, please follow the link below to select the time slot >that you will be available for the bar BoF. >http://www.doodle.com/ekbyza5rt75purw8 > >During this bar bof, we will discuss a possible way to move >p2p applications data plane into the network and how to >integrate it with p2p applications seamlessly. It will help to >save the last-mile bandwidth problem caused by p2p >applications. We will also discuss to use a possible simple >unified protocol to access the in-network storage, which will >make the in-network storage system a light one that does not >need to support various p2p applicaton protocols. > >The agenda will be published soon. If you have some topic to >be discussed during the bar BoF, please let me know. > >Best Regards, >Haibin >Skype: alexsonghw > > >Best Regards, >Haibin >Skype: alexsonghw > > > >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade > From gao.yang2@zte.com.cn Tue Jul 21 03:29:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB6B3A6DCE for ; Tue, 21 Jul 2009 03:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.955 X-Spam-Level: X-Spam-Status: No, score=-98.955 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLRFoQFGU9Kf for ; Tue, 21 Jul 2009 03:29:03 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 6737A28C0CE for ; Tue, 21 Jul 2009 03:28:55 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91102075036648; Tue, 21 Jul 2009 18:15:27 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 46629.2075036648; Tue, 21 Jul 2009 18:20:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6LAT2Mj087798 for ; Tue, 21 Jul 2009 18:29:02 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: p2psip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 21 Jul 2009 18:28:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-21 18:28:49 Content-Type: multipart/mixed; boundary="=_mixed 00398F83482575FA_=" X-MAIL: mse2.zte.com.cn n6LAT2Mj087798 Subject: [P2PSIP] A new proposal for SIP Usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 10:29:06 -0000 --=_mixed 00398F83482575FA_= Content-Type: multipart/alternative; boundary="=_alternative 00398F83482575FA_=" --=_alternative 00398F83482575FA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgaXQgaXMgc2lnbmlmaWNhdGl2ZSB0byB0YWxrIHRoZSB0b3BpYyBiZWZv cmUgdGhlIHRoZSB1cGxvYWQgDQpyZW9wZW5uaW5nIGRhdGUuDQpUaGUgYWNjZXNzb3J5IGlzIHRo ZSBkcmFmdC4NCg0KRmVlbCBmcmVlIGZvciBkaXNjdXNzaW9uLg0KDQpUaGFua3MuDQoNCkdhbw0K DQoNCnAycHNpcCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFkuIEdhbw0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZLiBNZW5nDQpJbnRlbmRlZCBzdGF0dXM6IFN0 YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUNCkV4 cGlyZXM6IEphbnVhcnkgMjIsIDIwMTAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SnVseSAyMSwgMjAwOQ0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgQSBOZXcgU0lQIFVzYWdl IGZvciBSRUxPQUQNCiAgICAgICAgICAgICAgIGRyYWZ0LWdhb3lhbmctcDJwc2lwLW5ldy1zaXAt dXNhZ2UtMDAudHh0DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1E cmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQog ICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiAgVGhpcyBkb2N1bWVudCBtYXkgbm90 IGJlIG1vZGlmaWVkLA0KICAgYW5kIGRlcml2YXRpdmUgd29ya3Mgb2YgaXQgbWF5IG5vdCBiZSBj cmVhdGVkLCBhbmQgaXQgbWF5IG5vdCBiZQ0KICAgcHVibGlzaGVkIGV4Y2VwdCBhcyBhbiBJbnRl cm5ldC1EcmFmdC4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJl YXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJh ZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0 ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0K DQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQg YXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAg VGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nl c3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJ bnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDIyLCAyMDEwLg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAwOSBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRo ZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHMgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRv Y3VtZW50IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pLg0KICAgUGxlYXNl IHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzDQogICBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdCB0byB0aGlzIGRvY3VtZW50 Lg0KDQoNCg0KDQoNCg0KDQpHYW8gJiBNZW5nICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkg MjIsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgQSBOZXcgU0lQIFVzYWdlIGZvciBSRUxPQUQgICAgICAgICAgICAgIEp1bHkgMjAwOQ0KDQoN CkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgcG9pbnRzIG91dCB0aGUgbWFpbiBkcmF3YmFj a3Mgb2YgdGhlIHNvbHV0aW9uIGluDQogICAiZHJhZnQtaWV0Zi1wMnBzaXAtc2lwLTAxIi4gIEFu ZCBzb2x2ZSBzdWNoIHByb2JsZW1zIGJ5IGludHJvZHVjaW5nIGENCiAgIG5ldyB3YXkuDQoNCg0K VGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICAyLiAgTWFpbiBkcmF3YmFj a3Mgb2YgdGhlIGN1cnJlbnQgc29sdXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQNCiAg ICAgMi4xLiAgSGlkZGVuIHRyb3VibGUgaW4gaW50ZXItZG9tYWluIGludGVyd29ya2luZyAuIC4g LiAuIC4gLiAuIC4gNA0KICAgICAyLjIuICBIaWRkZW4gdHJvdWJsZSBpbiBzaXAgdXNlcnMnIG1v YmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICAgICAgMi4yLjEuICBDb21wZWxsaW5n IHN1cHBvcnQgZm9yIHBlZXJzJyBtb2JpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIDQNCiAgICAgICAy LjIuMi4gIENodXJuIG9mIHRoZSBvdmVybGF5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNA0KICAgICAyLjMuICBFeGNsdXNpdml0eSB0b3dhcmRzIG92ZXJsYXkgY2xpZW50cyBp biBzaXAgdXNhZ2UgIC4gLiAuIC4gLiA0DQogICAzLiAgVGhlIG5ldyBzb2x1dGlvbiAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUNCiAgICAgMy4xLiAgU29s dXRpb24gaW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NQ0KICAgICAzLjIuICBNb3JlIG1lcml0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA1DQogICAgICAgMy4yLjEuICBIYWxmIHNwZW5kaW5nIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUNCiAgICAgICAzLjIuMi4gIFN1cHBv cnRpbmcgY2xpZW50cycgbW9iaWxpdHkgaW5oZXJlbnRseSAuIC4gLiAuIC4gLiAuIC4gNg0KICAg NC4gIE5vcm1hdGl2ZSByZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA3DQogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KR2FvICYgTWVuZyAgICAgICAgICAgICAgRXhw aXJlcyBKYW51YXJ5IDIyLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgIEEgTmV3IFNJUCBVc2FnZSBmb3IgUkVMT0FEICAgICAgICAgICAgICBK dWx5IDIwMDkNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIEFzIGRlc2NyaWJlZCBpbiAiZHJh ZnQtaWV0Zi1wMnBzaXAtc2lwLTAxIiwgUkVMT0FEJ3Mgb25seSByb2xlIGluIHNpcA0KICAgdXNh Z2UgaXMgdG8gc2V0IHVwIHRoZSBkaXJlY3QgU0lQIGNvbm5lY3Rpb24gYmV0d2VlbiBjYWxsZXIg YW5kDQogICBjYWxsZWUuICBTbywgdGhlIHNpcCB1c2VycyBhcmUgbW9yZSBsaWtlIGNsaWVudHMg dGhhbiBwZWVycyBoZXJlLg0KICAgQnV0ICJkcmFmdC1pZXRmLXAycHNpcC1zaXAtMDEiIHJlc3Ry aWN0cyB0aGF0IGNhbGxlciBhbmQgY2FsbGVlIGFyZQ0KICAgcGVlcnMgb2YgdGhlIG92ZXJsYXku DQoNCiAgIE1ha2luZyBiYWQgdGhpbmcgd29yc2UsIGNhbGxlZSBNVVNUIGJlIHBlZXJzIG9mIHRo ZSBvdmVybGF5IHdoaWxlDQogICB1c2luZyB0aGUgc29sdXRpb24gaW4gImRyYWZ0LWlldGYtcDJw c2lwLXNpcC0wMSIuICBUaGUgcmVhc29uIGlzIHRoYXQNCiAgIG9ubHkgcGVlcnMgY2FuIGJlIHJl YWNoYWJsZSBieSByb3V0aW5nIHRhYmxlIG9mIHRoZSBvdmVybGF5Lg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpHYW8gJiBNZW5nICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjIsIDIwMTAg ICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgQSBOZXcg U0lQIFVzYWdlIGZvciBSRUxPQUQgICAgICAgICAgICAgIEp1bHkgMjAwOQ0KDQoNCjIuICBNYWlu IGRyYXdiYWNrcyBvZiB0aGUgY3VycmVudCBzb2x1dGlvbg0KDQoyLjEuICBIaWRkZW4gdHJvdWJs ZSBpbiBpbnRlci1kb21haW4gaW50ZXJ3b3JraW5nDQoNCiAgIENvbnNpZGVyaW5nIGludGVyLWRv bWFpbiBpbnRlcndvcmtpbmcsIGNhbGxlciBjYW4gYmUgdXNlciBvZiBvdGhlcg0KICAgZG9tYWlu LiAgSWYgd2UgdXNlIHRoZSBzb2x1dGlvbiBpbiAiZHJhZnQtaWV0Zi1wMnBzaXAtc2lwLTAxIiwg dGhlcmUNCiAgIHNob3VsZCBiZSBhIG5vZGUgaW4gdGhlIG90aGVyIGRvbWFpbiBhcyBwZWVyIG9m IGNhbGxlZSdzIG92ZXJsYXkuDQogICBUaGF0IGlzIG5vdCBhY2NlcHRhYmxlIGZvciBvdmVybGF5 IG5ldHdvcmtpbmcgb3BlcmF0aW5nLCBhcyBzdG9yaW5nDQogICBkYXRhIGluIG90aGVyIGRvbWFp bidzIG5vZGUgY2FuIGJlIG5pZ2h0bWFyZS4NCg0KICAgSWYgd2UgbWFrZSBzaXAgdXNlcnMgb3V0 c2lkZSBvZiB0aGUgb3ZlcmxheSBqdXN0IGNsaWVudHMsIHRoZXJlIHdvdWxkDQogICBub3QgYmUg c3VjaCBwcm9ibGVtLiAgSW4gZmFjdCwgbWFraW5nIGNhbGxlciBqdXN0IGNsaWVudCBvZiB0aGUN CiAgIG92ZXJsYXkgY2FuIGdldCByaWQgb2YgdGhpcyBwcm9ibGVtLiAgU28sICJkcmFmdC1pZXRm LXAycHNpcC1zaXAtMDEiDQogICBjYW4gYWJvbGlzaCB0aGUgcmVzdHJpY3Rpb24gb2YgY2FsbGVy IGFzIHBlZXIuDQoNCiAgIFdoYXQgbmVlZCB0byBiZSBtZW50aW9uZWQgaXMgdGhhdCBzaXAgdXNl cnMgaW5zaWRlIHRoZSBvdmVybGF5IGNhbg0KICAgcmVnaXN0ZXIgaXRzZWxmIGZyb20gcGVlcnMg b2YgdGhlIG92ZXJsYXkgb3IgZnJvbSBjbGllbnRzLg0KDQoyLjIuICBIaWRkZW4gdHJvdWJsZSBp biBzaXAgdXNlcnMnIG1vYmlsaXR5DQoNCjIuMi4xLiAgQ29tcGVsbGluZyBzdXBwb3J0IGZvciBw ZWVycycgbW9iaWxpdHkNCg0KICAgQXMgc2lwIHVzZXJzIGFyZSBwZWVycywgc28gdGhlIG92ZXJs YXkgY29tcGVsbHMgdGhlIHN1cHBvcnQgb2YgcGVlcnMnDQogICBtb2JpbGl0eS4gIElmIHdlIG1h a2Ugc2lwIHVzZXIganVzdCBjbGllbnQgb2YgdGhlIG92ZXJsYXksIHRoZXJlDQogICB3b3VsZCBu b3QgYmUgc3VjaCBwcm9ibGVtLiAgSXQgbWVhbnMgdGhhdCB3ZSBjYW4gY29uc3RydWN0IGFuIG92 ZXJsYXkNCiAgIHN1cHBvcnRpbmcgY2xpZW50cycgbW9iaWxpdHkgd2l0aG91dCBuZWVkaW5nIHBl ZXJzJyBtb2JpbGl0eS4NCg0KMi4yLjIuICBDaHVybiBvZiB0aGUgb3ZlcmxheQ0KDQogICBDb25z aWRlcmluZyBzaXAgdXNlcnMnIG1vYmlsaXR5IGluIHdpcmVsZXNzIGFjY2VzcyBuZXR3b3JrDQog ICBlbnZpcm9ubWVudCwgdGhlcmUgd291bGQgYmUgbW9yZSBwcm9iYWJpbGl0eSBmb3IgcGVlcnMn IGpvaW5pbmcsDQogICBsZWF2aW5nIG9mIHRoZSBvdmVybGF5IHdoaWNoIGhhcyBpbXBhY3Qgb24g dGhlIGNodXJuIG9mIHRoZSBvdmVybGF5Lg0KICAgRnVydGhlciwgcGVlcnMgY2FuIGJlIG1vcmUg ZWFzaWx5IHRvIGxvc2UgaXRzIGNvbm5lY3Rpb24gYmVmb3JlDQogICBzZW5kaW5nIExlYXZlIG1l c3NhZ2UgaW4gc3VjaCB3aXJlbGVzcyBlbnZpcm9ubWVudC4gIEFuZCB0aGlzIHdpbGwNCiAgIG1h a2UgdGhlIGRhdGEgc3RvcmVkIGluIHRoZSBwZWVycyB1bnJlYWNoYWJsZS4NCg0KICAgSWYgd2Ug bWFrZSBtb2JpbGUgc2lwIHVzZXIganVzdCBjbGllbnQgb2YgdGhlIG92ZXJsYXksIHRoZXJlIHdv dWxkDQogICBub3QgYmUgc3VjaCBwcm9ibGVtLg0KDQoyLjMuICBFeGNsdXNpdml0eSB0b3dhcmRz IG92ZXJsYXkgY2xpZW50cyBpbiBzaXAgdXNhZ2UNCg0KICAgRXhjbHVzaXZpdHkgdG93YXJkcyBv dmVybGF5IGNsaWVudHMgaW4gc2lwIHVzYWdlIHdvdWxkIGhhdmUNCiAgIHJlc3RyaWN0aW9uIG9u IG9wZXJhdGluZyB3YXkgZm9yIG92ZXJsYXkgbmV0d29yayBvcGVyYXRvcnMuDQoNCg0KDQoNCg0K DQoNCg0KR2FvICYgTWVuZyAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDIyLCAyMDEwICAg ICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEEgTmV3IFNJ UCBVc2FnZSBmb3IgUkVMT0FEICAgICAgICAgICAgICBKdWx5IDIwMDkNCg0KDQozLiAgVGhlIG5l dyBzb2x1dGlvbg0KDQogICBUaGUgbWFpbiBkaWZmZXJlbmNlIGlzIHRoYXQgc2lwIHVzZXIgcmVn aXN0ZXJzIGhpcyBhZGRyZXNzIHdoaWxlIG5vdA0KICAgTm9kZUlELCB1bmRlciBoaXMgQU9SLg0K DQozLjEuICBTb2x1dGlvbiBpbnRyb2R1Y3Rpb24NCg0KICAgVGhlIHByb2Nlc3Mgb2YgYSBzaXAg Y2FsbDoNCg0KICAgMS4gIENhbGxlZSBzdG9yZXMgYSBtYXBwaW5nIGZyb20gaGlzIFVSSSB0byBo aXMgTm9kZS1JRCBpbiB0aGUNCiAgIG92ZXJsYXkuICBBbmQgdGhlIE5vZGVJRCBvZiB0aGUgcGVl ciBjaG9vc2VkIHRvIHN0b3JlIHRoZSBtYXBwaW5nIGhhcw0KICAgaGFzaCByZWxhdGlvbnNoaXAg d2l0aCBjYWxsZWUncyBVUkkuDQoNCiAgIDIuICBDYWxsZXIgbG9va3MgdXAgY2FsbGVlJ3MgVVJJ IGluIHRoZSBvdmVybGF5IGFuZCByZXRyaWV2ZXMNCiAgIGNhbGxlZSdzIGFkZHJlc3MuDQoNCiAg IDMuICBDYWxsZXIgdXNlcyBJQ0UncyBvZmZlci9hbnN3ZXIgdG8gZXhjaGFuZ2UgY2FsbGVyJ3Mg YW5kIGNhbGxlZSdzDQogICBjYW5kaWRhdGUgYWRkcmVzc2VzLg0KDQogICBUaGUgcHJvY2VzcyBv ZiBhIHNpcCBjYWxsDQoNCg0KICAgICAgQ2FsbGVyICAgICAgICAgICAgICBPdmVybGF5ICAgICAg ICAgICAgICAgIENhbGxlZQ0KICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0t LS0tLS0tLS0tLSBTdG9yZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAtLS0t LS0tLS0tLS0tLS0tLS0tPg0KICAgICAgRmV0Y2ggLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwt LS0tLS0tLS0tLS0tLS0tIEZldGNoDQoNCiAgICAgIElDRSBPZmZlciAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tIElDRSBBbnN3ZXINCiAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0gSUNFIENo ZWNrcyAtLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIElOVklURSAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gT0sNCiAgICAgIEFDSyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwtLS0tLS0tLS0tLS0gSUNFIENoZWNrcyBm b3IgbWVkaWEgLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLSBSVFAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgMQ0KDQozLjIuICBNb3JlIG1lcml0cw0KDQozLjIuMS4gIEhhbGYgc3BlbmRp bmcNCg0KICAgQWZ0ZXIgZmV0Y2hpbmcgdGhlIGNhbGxlZSdzIGFkZHJlc3MsIHRoZSBjYWxsZXIg Y2FuIHVzaW5nIElDRSBvZmZlci8NCiAgIGFuc3dlciBwcm9jZWR1cmUgZGlyZWN0bHksIHdpdGhv dXQgQXBwQXR0YWNoIHByb2NlZHVyZSBpbiB0aGUNCiAgIG92ZXJsYXkuDQoNCg0KDQpHYW8gJiBN ZW5nICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjIsIDIwMTAgICAgICAgICAgICAgICAg W1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgQSBOZXcgU0lQIFVzYWdlIGZvciBS RUxPQUQgICAgICAgICAgICAgIEp1bHkgMjAwOQ0KDQoNCjMuMi4yLiAgU3VwcG9ydGluZyBjbGll bnRzJyBtb2JpbGl0eSBpbmhlcmVudGx5DQoNCiAgIFdoZW4gY2FsbGVlIGNoYW5nZXMgaXRzIGFk ZHJlc3MsIGl0IGNhbiBzZW5kIGEgbmV3IHJlZ2lzdGVyaW5nDQogICBtZXNzYWdlIHRvIG92ZXJs YXkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KR2FvICYgTWVuZyAgICAg ICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDIyLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDZd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEEgTmV3IFNJUCBVc2FnZSBmb3IgUkVMT0FEICAg ICAgICAgICAgICBKdWx5IDIwMDkNCg0KDQo0LiAgTm9ybWF0aXZlIHJlZmVyZW5jZXMNCg0KICAg W0ktRC5pZXRmLW1tdXNpYy1pY2VdDQogICAgICAgICAgICAgIFJvc2VuYmVyZywgSi4sICJJbnRl cmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudA0KICAgICAgICAgICAgICAoSUNFKTog QSBQcm90b2NvbCBmb3IgTmV0d29yayBBZGRyZXNzICBUcmFuc2xhdG9yIChOQVQpDQogICAgICAg ICAgICAgIFRyYXZlcnNhbCBmb3IgT2ZmZXIvQW5zd2VyIFByb3RvY29scyIsDQogICAgICAgICAg ICAgIGRyYWZ0LWlldGYtbW11c2ljLWljZS0xOSAod29yayBpbiBwcm9ncmVzcyksIE9jdG9iZXIg MjAwNy4NCg0KICAgW0ktRC5pZXRmLXAycHNpcC1iYXNlXQ0KICAgICAgICAgICAgICBKZW5uaW5n cywgQy4sIExvd2VrYW1wLCBCLiwgUmVzY29ybGEsIEUuLCBCYXNldCwgUy4sIGFuZA0KICAgICAg ICAgICAgICBILiBTY2h1bHpyaW5uZSwgIlJFc291cmNlIExPY2F0aW9uIEFuZCBEaXNjb3Zlcnkg KFJFTE9BRCkNCiAgICAgICAgICAgICAgQmFzZSBQcm90b2NvbCIsIGRyYWZ0LWlldGYtcDJwc2lw LWJhc2UtMDMgKHdvcmsgaW4NCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBKdWx5IDIwMDkuDQoN CiAgIFtJLUQuaWV0Zi1wMnBzaXAtc2lwXQ0KICAgICAgICAgICAgICBKZW5uaW5ncywgQy4sIExv d2VrYW1wLCBCLiwgUmVzY29ybGEsIEUuLCBCYXNldCwgUy4sIGFuZA0KICAgICAgICAgICAgICBI LiBTY2h1bHpyaW5uZSwgIkEgU0lQIFVzYWdlIGZvciBSRUxPQUQiLA0KICAgICAgICAgICAgICBk cmFmdC1pZXRmLXAycHNpcC1zaXAtMDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDA5Lg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KR2FvICYgTWVuZyAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDIyLCAyMDEw ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEEgTmV3 IFNJUCBVc2FnZSBmb3IgUkVMT0FEICAgICAgICAgICAgICBKdWx5IDIwMDkNCg0KDQpBdXRob3Jz JyBBZGRyZXNzZXMNCg0KICAgR2FvIHlhbmcNCiAgIFpURQ0KICAgQ0hJTkENCg0KICAgRW1haWw6 IGdhby55YW5nMkB6dGUuY29tLmNuDQoNCg0KICAgTWVuZyBZdQ0KICAgWlRFDQogICBDSElOQQ0K DQogICBFbWFpbDogbWVuZy55dUB6dGUuY29tLmNuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkdhbyAmIE1l bmcgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyMiwgMjAxMCAgICAgICAgICAgICAgICBb UGFnZSA4XQ0KDA0KDQoNCg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K IFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4 NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlz IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1h aW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55 IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRo ZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2Vu ZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 00398F83482575FA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB0aGluayBpdCBpcyBzaWduaWZpY2F0 aXZlIHRvIHRhbGsNCnRoZSB0b3BpYyBiZWZvcmUgdGhlIHRoZSB1cGxvYWQgcmVvcGVubmluZyBk YXRlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGFjY2Vz c29yeSBpcyB0aGUgZHJhZnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5GZWVsIGZyZWUgZm9yIGRpc2N1c3Npb24uPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnAycHNpcCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwO1kuIEdhbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+SW50ZXJuZXQtRHJhZnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClkuIE1lbmc8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRz IFRyYWNrICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgWlRFPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5FeHBpcmVzOiBKYW51YXJ5IDIyLCAyMDEwICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0p1bHkgMjEsIDIwMDk8 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0EgTmV3IFNJUCBVc2FnZSBmb3IgUkVMT0FEPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO2RyYWZ0LWdhb3lhbmctcDJwc2lw LW5ldy1zaXAtdXNhZ2UtMDAudHh0PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5TdGF0dXMgb2YgdGhpcyBNZW1vPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7VGhpcyBJbnRlcm5ldC1EcmFm dCBpcw0Kc3VibWl0dGVkIHRvIElFVEYgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3Byb3Zp c2lvbnMgb2YgQkNQIDc4IGFuZA0KQkNQIDc5LiAmbmJzcDtUaGlzIGRvY3VtZW50IG1heSBub3Qg YmUgbW9kaWZpZWQsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7YW5kIGRlcml2YXRpdmUgd29ya3Mgb2YNCml0IG1heSBub3QgYmUgY3JlYXRl ZCwgYW5kIGl0IG1heSBub3QgYmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtwdWJsaXNoZWQgZXhjZXB0IGFzIGFuDQpJbnRlcm5ldC1EcmFm dC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDtJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcNCmRvY3VtZW50cyBvZiB0aGUgSW50 ZXJuZXQgRW5naW5lZXJpbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDtUYXNrIEZvcmNlIChJRVRGKSwgaXRzDQphcmVhcywgYW5kIGl0cyB3 b3JraW5nIGdyb3Vwcy4gJm5ic3A7Tm90ZSB0aGF0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWJ1dGUNCndvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LTwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0RyYWZ0cy48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0DQpkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7YW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwNCm9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7dGltZS4gJm5ic3A7SXQgaXMgaW5hcHByb3ByaWF0ZQ0KdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDttYXRlcmlhbCBvciB0byBjaXRlIHRoZW0NCm90 aGVyIHRoYW4gYXMgJnF1b3Q7d29yayBpbiBwcm9ncmVzcy4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtUaGUgbGlzdCBv ZiBjdXJyZW50IEludGVybmV0LURyYWZ0cw0KY2FuIGJlIGFjY2Vzc2VkIGF0PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7aHR0cDovL3d3dy5p ZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1RoZSBsaXN0IG9mIEludGVybmV0 LURyYWZ0DQpTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7aHR0cDovL3d3dy5p ZXRmLm9yZy9zaGFkb3cuaHRtbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtUaGlzIEludGVybmV0LURyYWZ0IHdpbGwNCmV4cGly ZSBvbiBKYW51YXJ5IDIyLCAyMDEwLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Q29weXJpZ2h0IE5vdGljZTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0NvcHlyaWdodCAoYykgMjAwOSBJ RVRGDQpUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtkb2N1bWVudCBhdXRo b3JzLiAmbmJzcDtBbGwNCnJpZ2h0cyByZXNlcnZlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QNCnRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1Byb3Zpc2lvbnMgUmVs YXRpbmcgdG8NCklFVEYgRG9jdW1lbnRzIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3B1YmxpY2F0 aW9uIG9mIHRoaXMgZG9jdW1lbnQNCihodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWlu Zm8pLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwO1BsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQpjYXJlZnVsbHksIGFzIHRoZXkgZGVz Y3JpYmUgeW91ciByaWdodHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDthbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdA0KdG8gdGhpcyBk b2N1bWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbyAmYW1wOyBNZW5nICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtFeHBpcmVzIEphbnVh cnkgMjIsIDIwMTAgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtbUGFnZSAxXTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+DDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW50ZXJu ZXQtRHJhZnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyBBIE5ldyBTSVAgVXNhZ2UgZm9y IFJFTE9BRCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 SnVseSAyMDA5PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5BYnN0cmFjdDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgcG9pbnRzIG91dA0KdGhlIG1haW4g ZHJhd2JhY2tzIG9mIHRoZSBzb2x1dGlvbiBpbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyZxdW90O2RyYWZ0LWlldGYtcDJwc2lwLXNpcC0w MSZxdW90Oy4NCiZuYnNwO0FuZCBzb2x2ZSBzdWNoIHByb2JsZW1zIGJ5IGludHJvZHVjaW5nIGE8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtu ZXcgd2F5LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+VGFibGUgb2YgQ29udGVudHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsxLiAmbmJzcDtJbnRyb2R1Y3Rpb24gJm5ic3A7 Lg0KLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzIuICZu YnNwO01haW4gZHJhd2JhY2tzDQpvZiB0aGUgY3VycmVudCBzb2x1dGlvbiAmbmJzcDsuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzIuMS4gJm5ic3A7SGlkZGVuDQp0cm91YmxlIGluIGlu dGVyLWRvbWFpbiBpbnRlcndvcmtpbmcgLiAuIC4gLiAuIC4gLiAuIDQ8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Mi4yLiAmbmJz cDtIaWRkZW4NCnRyb3VibGUgaW4gc2lwIHVzZXJzJyBtb2JpbGl0eSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Mi4yLjEuICZuYnNwO0NvbXBlbGxpbmcNCnN1cHBvcnQgZm9y IHBlZXJzJyBtb2JpbGl0eSAmbmJzcDsuIC4gLiAuIC4gLiAuIC4gNDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Mi4y LjIuICZuYnNwO0NodXJuDQpvZiB0aGUgb3ZlcmxheSAmbmJzcDsuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsyLjMuICZuYnNwO0V4Y2x1c2l2aXR5DQp0b3dhcmRzIG92 ZXJsYXkgY2xpZW50cyBpbiBzaXAgdXNhZ2UgJm5ic3A7LiAuIC4gLiAuIDQ8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDszLiAmbmJzcDtUaGUg bmV3IHNvbHV0aW9uDQombmJzcDsuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDszLjEuICZuYnNwO1NvbHV0aW9uDQppbnRyb2R1Y3Rpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzMuMi4gJm5ic3A7TW9yZQ0K bWVyaXRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzMuMi4xLiAmbmJzcDtIYWxmDQpzcGVuZGluZyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszLjIuMi4gJm5ic3A7U3Vw cG9ydGluZw0KY2xpZW50cycgbW9iaWxpdHkgaW5oZXJlbnRseSAuIC4gLiAuIC4gLiAuIC4gNjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzQu ICZuYnNwO05vcm1hdGl2ZSByZWZlcmVuY2VzDQombmJzcDsuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA3PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7QXV0aG9ycycgQWRkcmVzc2VzICZuYnNwOy4NCi4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA4PC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW8gJmFtcDsgTWVuZyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5IDIyLCAyMDEwICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W1Bh Z2UgMl08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPgw8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkludGVybmV0LURyYWZ0ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgQSBOZXcgU0lQIFVzYWdlIGZvciBSRUxPQUQgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0p1bHkgMjAwOTwvZm9u dD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gJm5i c3A7SW50cm9kdWN0aW9uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7QXMgZGVzY3JpYmVkIGluICZxdW90O2RyYWZ0LWlldGYtcDJw c2lwLXNpcC0wMSZxdW90OywNClJFTE9BRCdzIG9ubHkgcm9sZSBpbiBzaXA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDt1c2FnZSBpcyB0byBz ZXQgdXAgdGhlDQpkaXJlY3QgU0lQIGNvbm5lY3Rpb24gYmV0d2VlbiBjYWxsZXIgYW5kPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Y2FsbGVl LiAmbmJzcDtTbywgdGhlIHNpcA0KdXNlcnMgYXJlIG1vcmUgbGlrZSBjbGllbnRzIHRoYW4gcGVl cnMgaGVyZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDtCdXQgJnF1b3Q7ZHJhZnQtaWV0Zi1wMnBzaXAtc2lwLTAxJnF1b3Q7DQpyZXN0cmlj dHMgdGhhdCBjYWxsZXIgYW5kIGNhbGxlZSBhcmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtwZWVycyBvZiB0aGUgb3ZlcmxheS48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtN YWtpbmcgYmFkIHRoaW5nIHdvcnNlLA0KY2FsbGVlIE1VU1QgYmUgcGVlcnMgb2YgdGhlIG92ZXJs YXkgd2hpbGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDt1c2luZyB0aGUgc29sdXRpb24gaW4gJnF1b3Q7ZHJhZnQtaWV0Zi1wMnBzaXAtc2lw LTAxJnF1b3Q7Lg0KJm5ic3A7VGhlIHJlYXNvbiBpcyB0aGF0PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7b25seSBwZWVycyBjYW4gYmUgcmVh Y2hhYmxlDQpieSByb3V0aW5nIHRhYmxlIG9mIHRoZSBvdmVybGF5LjwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvICZhbXA7IE1lbmcgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0V4cGlyZXMgSmFu dWFyeSAyMiwgMjAxMCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1tQYWdlIDNdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4MPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbnRl cm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEEgTmV3IFNJUCBVc2FnZSBm b3IgUkVMT0FEICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDtKdWx5IDIwMDk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjIuICZuYnNwO01haW4gZHJhd2JhY2tzIG9mIHRoZSBjdXJyZW50DQpzb2x1dGlv bjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4xLiAm bmJzcDtIaWRkZW4gdHJvdWJsZSBpbiBpbnRlci1kb21haW4NCmludGVyd29ya2luZzwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0Nv bnNpZGVyaW5nIGludGVyLWRvbWFpbg0KaW50ZXJ3b3JraW5nLCBjYWxsZXIgY2FuIGJlIHVzZXIg b2Ygb3RoZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDtkb21haW4uICZuYnNwO0lmIHdlIHVzZQ0KdGhlIHNvbHV0aW9uIGluICZxdW90O2Ry YWZ0LWlldGYtcDJwc2lwLXNpcC0wMSZxdW90OywgdGhlcmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtzaG91bGQgYmUgYSBub2RlIGluIHRo ZQ0Kb3RoZXIgZG9tYWluIGFzIHBlZXIgb2YgY2FsbGVlJ3Mgb3ZlcmxheS48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtUaGF0IGlzIG5vdCBh Y2NlcHRhYmxlDQpmb3Igb3ZlcmxheSBuZXR3b3JraW5nIG9wZXJhdGluZywgYXMgc3RvcmluZzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2Rh dGEgaW4gb3RoZXIgZG9tYWluJ3MNCm5vZGUgY2FuIGJlIG5pZ2h0bWFyZS48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtJZiB3ZSBt YWtlIHNpcCB1c2VycyBvdXRzaWRlDQpvZiB0aGUgb3ZlcmxheSBqdXN0IGNsaWVudHMsIHRoZXJl IHdvdWxkPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7bm90IGJlIHN1Y2ggcHJvYmxlbS4gJm5ic3A7SW4NCmZhY3QsIG1ha2luZyBjYWxsZXIg anVzdCBjbGllbnQgb2YgdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7b3ZlcmxheSBjYW4gZ2V0IHJpZCBvZg0KdGhpcyBwcm9ibGVtLiAm bmJzcDtTbywgJnF1b3Q7ZHJhZnQtaWV0Zi1wMnBzaXAtc2lwLTAxJnF1b3Q7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Y2FuIGFib2xpc2gg dGhlIHJlc3RyaWN0aW9uDQpvZiBjYWxsZXIgYXMgcGVlci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtXaGF0IG5lZWQgdG8gYmUg bWVudGlvbmVkDQppcyB0aGF0IHNpcCB1c2VycyBpbnNpZGUgdGhlIG92ZXJsYXkgY2FuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7cmVnaXN0 ZXIgaXRzZWxmIGZyb20gcGVlcnMNCm9mIHRoZSBvdmVybGF5IG9yIGZyb20gY2xpZW50cy48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuMi4gJm5ic3A7 SGlkZGVuIHRyb3VibGUgaW4gc2lwIHVzZXJzJw0KbW9iaWxpdHk8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuMi4xLiAmbmJzcDtDb21wZWxsaW5nIHN1 cHBvcnQgZm9yDQpwZWVycycgbW9iaWxpdHk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtBcyBzaXAgdXNlcnMgYXJlIHBlZXJzLA0K c28gdGhlIG92ZXJsYXkgY29tcGVsbHMgdGhlIHN1cHBvcnQgb2YgcGVlcnMnPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bW9iaWxpdHkuICZu YnNwO0lmIHdlIG1ha2UNCnNpcCB1c2VyIGp1c3QgY2xpZW50IG9mIHRoZSBvdmVybGF5LCB0aGVy ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw O3dvdWxkIG5vdCBiZSBzdWNoIHByb2JsZW0uDQombmJzcDtJdCBtZWFucyB0aGF0IHdlIGNhbiBj b25zdHJ1Y3QgYW4gb3ZlcmxheTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwO3N1cHBvcnRpbmcgY2xpZW50cycgbW9iaWxpdHkNCndpdGhvdXQg bmVlZGluZyBwZWVycycgbW9iaWxpdHkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4yLjIuMi4gJm5ic3A7Q2h1cm4gb2YgdGhlIG92ZXJsYXk8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtD b25zaWRlcmluZyBzaXAgdXNlcnMnDQptb2JpbGl0eSBpbiB3aXJlbGVzcyBhY2Nlc3MgbmV0d29y azwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw O2Vudmlyb25tZW50LCB0aGVyZSB3b3VsZA0KYmUgbW9yZSBwcm9iYWJpbGl0eSBmb3IgcGVlcnMn IGpvaW5pbmcsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7bGVhdmluZyBvZiB0aGUgb3ZlcmxheQ0Kd2hpY2ggaGFzIGltcGFjdCBvbiB0aGUg Y2h1cm4gb2YgdGhlIG92ZXJsYXkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7RnVydGhlciwgcGVlcnMgY2FuIGJlIG1vcmUNCmVhc2lseSB0 byBsb3NlIGl0cyBjb25uZWN0aW9uIGJlZm9yZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3NlbmRpbmcgTGVhdmUgbWVzc2FnZSBpbg0Kc3Vj aCB3aXJlbGVzcyBlbnZpcm9ubWVudC4gJm5ic3A7QW5kIHRoaXMgd2lsbDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO21ha2UgdGhlIGRhdGEg c3RvcmVkIGluDQp0aGUgcGVlcnMgdW5yZWFjaGFibGUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7SWYgd2UgbWFrZSBtb2JpbGUg c2lwIHVzZXINCmp1c3QgY2xpZW50IG9mIHRoZSBvdmVybGF5LCB0aGVyZSB3b3VsZDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO25vdCBiZSBz dWNoIHByb2JsZW0uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4yLjMuICZuYnNwO0V4Y2x1c2l2aXR5IHRvd2FyZHMgb3ZlcmxheQ0KY2xpZW50cyBpbiBz aXAgdXNhZ2U8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDtFeGNsdXNpdml0eSB0b3dhcmRzIG92ZXJsYXkNCmNsaWVudHMgaW4gc2lw IHVzYWdlIHdvdWxkIGhhdmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDtyZXN0cmljdGlvbiBvbiBvcGVyYXRpbmcNCndheSBmb3Igb3Zlcmxh eSBuZXR3b3JrIG9wZXJhdG9ycy48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdh byAmYW1wOyBNZW5nICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtFeHBpcmVzIEphbnVhcnkgMjIsIDIwMTAgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbUGFnZSA0XTwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+DDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+SW50ZXJuZXQtRHJhZnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyBB IE5ldyBTSVAgVXNhZ2UgZm9yIFJFTE9BRCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7SnVseSAyMDA5PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4zLiAmbmJzcDtUaGUgbmV3IHNvbHV0aW9uPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 VGhlIG1haW4gZGlmZmVyZW5jZSBpcw0KdGhhdCBzaXAgdXNlciByZWdpc3RlcnMgaGlzIGFkZHJl c3Mgd2hpbGUgbm90PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7Tm9kZUlELCB1bmRlciBoaXMgQU9SLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+My4xLiAmbmJzcDtTb2x1dGlvbiBpbnRyb2R1Y3Rp b248L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDtUaGUgcHJvY2VzcyBvZiBhIHNpcCBjYWxsOjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzEuICZuYnNwO0NhbGxlZSBz dG9yZXMNCmEgbWFwcGluZyBmcm9tIGhpcyBVUkkgdG8gaGlzIE5vZGUtSUQgaW4gdGhlPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7b3Zlcmxh eS4gJm5ic3A7QW5kIHRoZQ0KTm9kZUlEIG9mIHRoZSBwZWVyIGNob29zZWQgdG8gc3RvcmUgdGhl IG1hcHBpbmcgaGFzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7aGFzaCByZWxhdGlvbnNoaXAgd2l0aA0KY2FsbGVlJ3MgVVJJLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzIu ICZuYnNwO0NhbGxlciBsb29rcyB1cA0KY2FsbGVlJ3MgVVJJIGluIHRoZSBvdmVybGF5IGFuZCBy ZXRyaWV2ZXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDtjYWxsZWUncyBhZGRyZXNzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzMuICZuYnNwO0NhbGxlciB1c2VzIElDRSdz DQpvZmZlci9hbnN3ZXIgdG8gZXhjaGFuZ2UgY2FsbGVyJ3MgYW5kIGNhbGxlZSdzPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Y2FuZGlkYXRl IGFkZHJlc3Nlcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDtUaGUgcHJvY2VzcyBvZiBhIHNpcCBjYWxsPC9mb250Pg0KPGJyPg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyBDYWxsZXIgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO092ZXJsYXkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDtDYWxsZWU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDst LS0tLS0tLS0tLS0tLS0tLS0tDQpTdG9yZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7U3RvcmUgLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IEZldGNoIC0tLS0tLS0tLS0t LS0tLS0mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbHQ7LS0tLS0tLS0tLS0tLS0tLQ0KRmV0Y2g8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 IElDRSBPZmZlciAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJQ0UgQW5zd2Vy PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tDQpJQ0UgQ2hlY2tzIC0tLS0tLS0tLS0tLS0t LS0tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgSU5WSVRFIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KT0s8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IEFDSyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDstLS0tLS0tLS0tLS0NCklDRSBDaGVja3MgZm9y IG1lZGlhIC0tLS0tLS0tLS0tLS0mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0N ClJUUCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0OzwvZm9udD4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWd1cmUNCjE8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuMi4gJm5ic3A7TW9yZSBtZXJp dHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuMi4x LiAmbmJzcDtIYWxmIHNwZW5kaW5nPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7QWZ0ZXIgZmV0Y2hpbmcgdGhlIGNhbGxlZSdzDQph ZGRyZXNzLCB0aGUgY2FsbGVyIGNhbiB1c2luZyBJQ0Ugb2ZmZXIvPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YW5zd2VyIHByb2NlZHVyZSBk aXJlY3RseSwNCndpdGhvdXQgQXBwQXR0YWNoIHByb2NlZHVyZSBpbiB0aGU8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtvdmVybGF5LjwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ R2FvICZhbXA7IE1lbmcgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0V4cGlyZXMgSmFudWFyeSAyMiwgMjAxMCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDVdPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4MPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5JbnRlcm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 IEEgTmV3IFNJUCBVc2FnZSBmb3IgUkVMT0FEICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDtKdWx5IDIwMDk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuMi4yLiAmbmJzcDtTdXBwb3J0aW5nIGNsaWVu dHMnIG1vYmlsaXR5DQppbmhlcmVudGx5PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7V2hlbiBjYWxsZWUgY2hhbmdlcyBpdHMNCmFk ZHJlc3MsIGl0IGNhbiBzZW5kIGEgbmV3IHJlZ2lzdGVyaW5nPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bWVzc2FnZSB0byBvdmVybGF5Ljwv Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvICZhbXA7IE1lbmcgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0V4cGlyZXMgSmFu dWFyeSAyMiwgMjAxMCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1tQYWdlIDZdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4MPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbnRl cm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEEgTmV3IFNJUCBVc2FnZSBm b3IgUkVMT0FEICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDtKdWx5IDIwMDk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjQuICZuYnNwO05vcm1hdGl2ZSByZWZlcmVuY2VzPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7W0ktRC5pZXRmLW1t dXNpYy1pY2VdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IFJvc2VuYmVyZywg Si4sICZxdW90O0ludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IChJQ0UpOiBBIFByb3RvY29sIGZvciBOZXR3b3Jr IEFkZHJlc3MgJm5ic3A7VHJhbnNsYXRvciAoTkFUKTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyBUcmF2ZXJzYWwgZm9yIE9mZmVyL0Fuc3dlciBQcm90b2NvbHMmcXVvdDssPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IGRyYWZ0LWlldGYtbW11c2ljLWljZS0x OSAod29yayBpbiBwcm9ncmVzcyksIE9jdG9iZXIgMjAwNy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtbSS1ELmlldGYtcDJwc2lw LWJhc2VdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEplbm5pbmdzLCBDLiwg TG93ZWthbXAsIEIuLCBSZXNjb3JsYSwgRS4sIEJhc2V0LCBTLiwgYW5kPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7IEguIFNjaHVsenJpbm5lLCAmcXVvdDtSRXNvdXJjZSBMT2Nh dGlvbiBBbmQgRGlzY292ZXJ5IChSRUxPQUQpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7IEJhc2UgUHJvdG9jb2wmcXVvdDssIGRyYWZ0LWlldGYtcDJwc2lwLWJhc2UtMDMgKHdv cmsgaW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgcHJvZ3Jlc3MpLCBKdWx5 IDIwMDkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7W0ktRC5pZXRmLXAycHNpcC1zaXBdPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7IEplbm5pbmdzLCBDLiwgTG93ZWthbXAsIEIuLCBSZXNjb3JsYSwgRS4sIEJh c2V0LCBTLiwgYW5kPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEguIFNjaHVs enJpbm5lLCAmcXVvdDtBIFNJUCBVc2FnZSBmb3IgUkVMT0FEJnF1b3Q7LDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyBkcmFmdC1pZXRmLXAycHNpcC1zaXAtMDEgKHdvcmsgaW4g cHJvZ3Jlc3MpLCBNYXJjaCAyMDA5LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvICZhbXA7IE1lbmcgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0V4cGlyZXMgSmFudWFy eSAyMiwgMjAxMCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1tQYWdlIDddPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4MPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbnRlcm5l dC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEEgTmV3IFNJUCBVc2FnZSBmb3Ig UkVMT0FEICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtK dWx5IDIwMDk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkF1dGhvcnMnIEFkZHJlc3NlczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0dhbyB5YW5nPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7WlRFPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Q0hJTkE8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtFbWFp bDogZ2FvLnlhbmcyQHp0ZS5jb20uY248L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtNZW5nIFl1PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7WlRFPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Q0hJTkE8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtF bWFpbDogbWVuZy55dUB6dGUuY29tLmNuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5HYW8gJmFtcDsgTWVuZyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5IDIyLCAyMDEwICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W1BhZ2UgOF08L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPgw8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+ DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUt NTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj48cHJlPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNw O0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5m b3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7 aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVy J3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVk Jm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWlu Jm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZu YnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7 dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtl bWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3 aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRl bmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9t Jm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNw O2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJy b3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVz c2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21l c3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVz ZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJz cDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00398F83482575FA_=-- --=_mixed 00398F83482575FA_= Content-Type: text/plain; name="draft-gaoyang-p2psip-new-sip-usage-00.txt" Content-Disposition: attachment; filename="draft-gaoyang-p2psip-new-sip-usage-00.txt" Content-Transfer-Encoding: quoted-printable p2psip Y. Gao Internet-Draft Y. Meng Intended status: Standards Track ZTE Expires: January 22, 2010 July 21, 2009 A New SIP Usage for RELOAD draft-gaoyang-p2psip-new-sip-usage-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Gao & Meng Expires January 22, 2010 [Page 1] =0C Internet-Draft A New SIP Usage for RELOAD July 2009 Abstract This document points out the main drawbacks of the solution in "draft-ietf-p2psip-sip-01". And solve such problems by introducing a new way. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Main drawbacks of the current solution . . . . . . . . . . . . 4 2.1. Hidden trouble in inter-domain interworking . . . . . . . . 4 2.2. Hidden trouble in sip users' mobility . . . . . . . . . . . 4 2.2.1. Compelling support for peers' mobility . . . . . . . . 4 2.2.2. Churn of the overlay . . . . . . . . . . . . . . . . . 4 2.3. Exclusivity towards overlay clients in sip usage . . . . . 4 3. The new solution . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Solution introduction . . . . . . . . . . . . . . . . . . . 5 3.2. More merits . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Half spending . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Supporting clients' mobility inherently . . . . . . . . 6 4. Normative references . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Gao & Meng Expires January 22, 2010 [Page 2] =0C Internet-Draft A New SIP Usage for RELOAD July 2009 1. Introduction As described in "draft-ietf-p2psip-sip-01", RELOAD's only role in sip usage is to set up the direct SIP connection between caller and callee. So, the sip users are more like clients than peers here. But "draft-ietf-p2psip-sip-01" restricts that caller and callee are peers of the overlay. Making bad thing worse, callee MUST be peers of the overlay while using the solution in "draft-ietf-p2psip-sip-01". The reason is that only peers can be reachable by routing table of the overlay. Gao & Meng Expires January 22, 2010 [Page 3] =0C Internet-Draft A New SIP Usage for RELOAD July 2009 2. Main drawbacks of the current solution 2.1. Hidden trouble in inter-domain interworking Considering inter-domain interworking, caller can be user of other domain. If we use the solution in "draft-ietf-p2psip-sip-01", there should be a node in the other domain as peer of callee's overlay. That is not acceptable for overlay networking operating, as storing data in other domain's node can be nightmare. If we make sip users outside of the overlay just clients, there would not be such problem. In fact, making caller just client of the overlay can get rid of this problem. So, "draft-ietf-p2psip-sip-01" can abolish the restriction of caller as peer. What need to be mentioned is that sip users inside the overlay can register itself from peers of the overlay or from clients. 2.2. Hidden trouble in sip users' mobility 2.2.1. Compelling support for peers' mobility As sip users are peers, so the overlay compells the support of peers' mobility. If we make sip user just client of the overlay, there would not be such problem. It means that we can construct an overlay supporting clients' mobility without needing peers' mobility. 2.2.2. Churn of the overlay Considering sip users' mobility in wireless access network environment, there would be more probability for peers' joining, leaving of the overlay which has impact on the churn of the overlay. Further, peers can be more easily to lose its connection before sending Leave message in such wireless environment. And this will make the data stored in the peers unreachable. If we make mobile sip user just client of the overlay, there would not be such problem. 2.3. Exclusivity towards overlay clients in sip usage Exclusivity towards overlay clients in sip usage would have restriction on operating way for overlay network operators. Gao & Meng Expires January 22, 2010 [Page 4] =0C Internet-Draft A New SIP Usage for RELOAD July 2009 3. The new solution The main difference is that sip user registers his address while not NodeID, under his AOR. 3.1. Solution introduction The process of a sip call: 1. Callee stores a mapping from his URI to his Node-ID in the overlay. And the NodeID of the peer choosed to store the mapping has hash relationship with callee's URI. 2. Caller looks up callee's URI in the overlay and retrieves callee's address. 3. Caller uses ICE's offer/answer to exchange caller's and callee's candidate addresses. The process of a sip call Caller Overlay Callee ------------------------------------------------- <------------------- Store Store -------------------> Fetch ----------------> <---------------- Fetch ICE Offer --------------------------------------> <------------------------------------- ICE Answer <------------------ ICE Checks -----------------> INVITE -----------------------------------------> <--------------------------------------------- OK ACK --------------------------------------------> <------------ ICE Checks for media -------------> <-------------------- RTP ----------------------> Figure 1 3.2. More merits 3.2.1. Half spending After fetching the callee's address, the caller can using ICE offer/ answer procedure directly, without AppAttach procedure in the overlay. Gao & Meng Expires January 22, 2010 [Page 5] =0C Internet-Draft A New SIP Usage for RELOAD July 2009 3.2.2. Supporting clients' mobility inherently When callee changes its address, it can send a new registering message to overlay. Gao & Meng Expires January 22, 2010 [Page 6] =0C Internet-Draft A New SIP Usage for RELOAD July 2009 4. Normative references [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-03 (work in progress), July 2009. [I-D.ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "A SIP Usage for RELOAD", draft-ietf-p2psip-sip-01 (work in progress), March 2009. Gao & Meng Expires January 22, 2010 [Page 7] =0C Internet-Draft A New SIP Usage for RELOAD July 2009 Authors' Addresses Gao yang ZTE CHINA Email: gao.yang2@zte.com.cn Meng Yu ZTE CHINA Email: meng.yu@zte.com.cn Gao & Meng Expires January 22, 2010 [Page 8] =0C --=_mixed 00398F83482575FA_=-- From gao.yang2@zte.com.cn Tue Jul 21 03:35:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055E53A6A0F for ; Tue, 21 Jul 2009 03:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.955 X-Spam-Level: X-Spam-Status: No, score=-98.955 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xzgg2Jeouah for ; Tue, 21 Jul 2009 03:35:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6792E3A677D for ; Tue, 21 Jul 2009 03:35:25 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111642075036648; Tue, 21 Jul 2009 18:17:19 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 46629.2075036648; Tue, 21 Jul 2009 18:27:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6LAZCat005601 for ; Tue, 21 Jul 2009 18:35:12 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: p2psip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 21 Jul 2009 18:34:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-21 18:35:01, Serialize complete at 2009-07-21 18:35:01 Content-Type: multipart/alternative; boundary="=_alternative 003A20E6482575FA_=" X-MAIL: mse1.zte.com.cn n6LAZCat005601 Subject: [P2PSIP] A new proposal for SIP Usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 10:35:30 -0000 This is a multipart message in MIME format. --=_alternative 003A20E6482575FA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgaXQgaXMgc2lnbmlmaWNhdGl2ZSB0byB0YWxrIHRoZSB0b3BpYyBiZWZv cmUgdGhlIHRoZSB1cGxvYWQgDQpyZW9wZW5uaW5nIGRhdGUuDQpUaGUgYWNjZXNzb3J5IGlzIHRo ZSBkcmFmdC4NCg0KRmVlbCBmcmVlIGZvciBkaXNjdXNzaW9uLg0KDQpUaGFua3MuDQoNCkdhbw0K DQoNCnAycHNpcCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFkuIEdhbw0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZLiBNZW5nDQpJbnRlbmRlZCBzdGF0dXM6IFN0 YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUNCkV4 cGlyZXM6IEphbnVhcnkgMjIsIDIwMTAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SnVseSAyMSwgMjAwOQ0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgQSBOZXcgU0lQIFVzYWdl IGZvciBSRUxPQUQNCiAgICAgICAgICAgICAgIGRyYWZ0LWdhb3lhbmctcDJwc2lwLW5ldy1zaXAt dXNhZ2UtMDAudHh0DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1E cmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQog ICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiAgVGhpcyBkb2N1bWVudCBtYXkgbm90 IGJlIG1vZGlmaWVkLA0KICAgYW5kIGRlcml2YXRpdmUgd29ya3Mgb2YgaXQgbWF5IG5vdCBiZSBj cmVhdGVkLCBhbmQgaXQgbWF5IG5vdCBiZQ0KICAgcHVibGlzaGVkIGV4Y2VwdCBhcyBhbiBJbnRl cm5ldC1EcmFmdC4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJl YXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJh ZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0 ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0K DQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQg YXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAg VGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nl c3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJ bnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDIyLCAyMDEwLg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAwOSBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRo ZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHMgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRv Y3VtZW50IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pLg0KICAgUGxlYXNl IHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzDQogICBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdCB0byB0aGlzIGRvY3VtZW50 Lg0KDQoNCg0KDQoNCg0KDQpHYW8gJiBNZW5nICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkg MjIsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgQSBOZXcgU0lQIFVzYWdlIGZvciBSRUxPQUQgICAgICAgICAgICAgIEp1bHkgMjAwOQ0KDQoN CkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgcG9pbnRzIG91dCB0aGUgbWFpbiBkcmF3YmFj a3Mgb2YgdGhlIHNvbHV0aW9uIGluDQogICAiZHJhZnQtaWV0Zi1wMnBzaXAtc2lwLTAxIi4gIEFu ZCBzb2x2ZSBzdWNoIHByb2JsZW1zIGJ5IGludHJvZHVjaW5nIGENCiAgIG5ldyB3YXkuDQoNCg0K VGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICAyLiAgTWFpbiBkcmF3YmFj a3Mgb2YgdGhlIGN1cnJlbnQgc29sdXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQNCiAg ICAgMi4xLiAgSGlkZGVuIHRyb3VibGUgaW4gaW50ZXItZG9tYWluIGludGVyd29ya2luZyAuIC4g LiAuIC4gLiAuIC4gNA0KICAgICAyLjIuICBIaWRkZW4gdHJvdWJsZSBpbiBzaXAgdXNlcnMnIG1v YmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICAgICAgMi4yLjEuICBDb21wZWxsaW5n IHN1cHBvcnQgZm9yIHBlZXJzJyBtb2JpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIDQNCiAgICAgICAy LjIuMi4gIENodXJuIG9mIHRoZSBvdmVybGF5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNA0KICAgICAyLjMuICBFeGNsdXNpdml0eSB0b3dhcmRzIG92ZXJsYXkgY2xpZW50cyBp biBzaXAgdXNhZ2UgIC4gLiAuIC4gLiA0DQogICAzLiAgVGhlIG5ldyBzb2x1dGlvbiAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUNCiAgICAgMy4xLiAgU29s dXRpb24gaW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NQ0KICAgICAzLjIuICBNb3JlIG1lcml0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA1DQogICAgICAgMy4yLjEuICBIYWxmIHNwZW5kaW5nIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUNCiAgICAgICAzLjIuMi4gIFN1cHBv cnRpbmcgY2xpZW50cycgbW9iaWxpdHkgaW5oZXJlbnRseSAuIC4gLiAuIC4gLiAuIC4gNg0KICAg NC4gIE5vcm1hdGl2ZSByZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA3DQogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KR2FvICYgTWVuZyAgICAgICAgICAgICAgRXhw aXJlcyBKYW51YXJ5IDIyLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgIEEgTmV3IFNJUCBVc2FnZSBmb3IgUkVMT0FEICAgICAgICAgICAgICBK dWx5IDIwMDkNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIEFzIGRlc2NyaWJlZCBpbiAiZHJh ZnQtaWV0Zi1wMnBzaXAtc2lwLTAxIiwgUkVMT0FEJ3Mgb25seSByb2xlIGluIHNpcA0KICAgdXNh Z2UgaXMgdG8gc2V0IHVwIHRoZSBkaXJlY3QgU0lQIGNvbm5lY3Rpb24gYmV0d2VlbiBjYWxsZXIg YW5kDQogICBjYWxsZWUuICBTbywgdGhlIHNpcCB1c2VycyBhcmUgbW9yZSBsaWtlIGNsaWVudHMg dGhhbiBwZWVycyBoZXJlLg0KICAgQnV0ICJkcmFmdC1pZXRmLXAycHNpcC1zaXAtMDEiIHJlc3Ry aWN0cyB0aGF0IGNhbGxlciBhbmQgY2FsbGVlIGFyZQ0KICAgcGVlcnMgb2YgdGhlIG92ZXJsYXku DQoNCiAgIE1ha2luZyBiYWQgdGhpbmcgd29yc2UsIGNhbGxlZSBNVVNUIGJlIHBlZXJzIG9mIHRo ZSBvdmVybGF5IHdoaWxlDQogICB1c2luZyB0aGUgc29sdXRpb24gaW4gImRyYWZ0LWlldGYtcDJw c2lwLXNpcC0wMSIuICBUaGUgcmVhc29uIGlzIHRoYXQNCiAgIG9ubHkgcGVlcnMgY2FuIGJlIHJl YWNoYWJsZSBieSByb3V0aW5nIHRhYmxlIG9mIHRoZSBvdmVybGF5Lg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpHYW8gJiBNZW5nICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjIsIDIwMTAg ICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgQSBOZXcg U0lQIFVzYWdlIGZvciBSRUxPQUQgICAgICAgICAgICAgIEp1bHkgMjAwOQ0KDQoNCjIuICBNYWlu IGRyYXdiYWNrcyBvZiB0aGUgY3VycmVudCBzb2x1dGlvbg0KDQoyLjEuICBIaWRkZW4gdHJvdWJs ZSBpbiBpbnRlci1kb21haW4gaW50ZXJ3b3JraW5nDQoNCiAgIENvbnNpZGVyaW5nIGludGVyLWRv bWFpbiBpbnRlcndvcmtpbmcsIGNhbGxlciBjYW4gYmUgdXNlciBvZiBvdGhlcg0KICAgZG9tYWlu LiAgSWYgd2UgdXNlIHRoZSBzb2x1dGlvbiBpbiAiZHJhZnQtaWV0Zi1wMnBzaXAtc2lwLTAxIiwg dGhlcmUNCiAgIHNob3VsZCBiZSBhIG5vZGUgaW4gdGhlIG90aGVyIGRvbWFpbiBhcyBwZWVyIG9m IGNhbGxlZSdzIG92ZXJsYXkuDQogICBUaGF0IGlzIG5vdCBhY2NlcHRhYmxlIGZvciBvdmVybGF5 IG5ldHdvcmtpbmcgb3BlcmF0aW5nLCBhcyBzdG9yaW5nDQogICBkYXRhIGluIG90aGVyIGRvbWFp bidzIG5vZGUgY2FuIGJlIG5pZ2h0bWFyZS4NCg0KICAgSWYgd2UgbWFrZSBzaXAgdXNlcnMgb3V0 c2lkZSBvZiB0aGUgb3ZlcmxheSBqdXN0IGNsaWVudHMsIHRoZXJlIHdvdWxkDQogICBub3QgYmUg c3VjaCBwcm9ibGVtLiAgSW4gZmFjdCwgbWFraW5nIGNhbGxlciBqdXN0IGNsaWVudCBvZiB0aGUN CiAgIG92ZXJsYXkgY2FuIGdldCByaWQgb2YgdGhpcyBwcm9ibGVtLiAgU28sICJkcmFmdC1pZXRm LXAycHNpcC1zaXAtMDEiDQogICBjYW4gYWJvbGlzaCB0aGUgcmVzdHJpY3Rpb24gb2YgY2FsbGVy IGFzIHBlZXIuDQoNCiAgIFdoYXQgbmVlZCB0byBiZSBtZW50aW9uZWQgaXMgdGhhdCBzaXAgdXNl cnMgaW5zaWRlIHRoZSBvdmVybGF5IGNhbg0KICAgcmVnaXN0ZXIgaXRzZWxmIGZyb20gcGVlcnMg b2YgdGhlIG92ZXJsYXkgb3IgZnJvbSBjbGllbnRzLg0KDQoyLjIuICBIaWRkZW4gdHJvdWJsZSBp biBzaXAgdXNlcnMnIG1vYmlsaXR5DQoNCjIuMi4xLiAgQ29tcGVsbGluZyBzdXBwb3J0IGZvciBw ZWVycycgbW9iaWxpdHkNCg0KICAgQXMgc2lwIHVzZXJzIGFyZSBwZWVycywgc28gdGhlIG92ZXJs YXkgY29tcGVsbHMgdGhlIHN1cHBvcnQgb2YgcGVlcnMnDQogICBtb2JpbGl0eS4gIElmIHdlIG1h a2Ugc2lwIHVzZXIganVzdCBjbGllbnQgb2YgdGhlIG92ZXJsYXksIHRoZXJlDQogICB3b3VsZCBu b3QgYmUgc3VjaCBwcm9ibGVtLiAgSXQgbWVhbnMgdGhhdCB3ZSBjYW4gY29uc3RydWN0IGFuIG92 ZXJsYXkNCiAgIHN1cHBvcnRpbmcgY2xpZW50cycgbW9iaWxpdHkgd2l0aG91dCBuZWVkaW5nIHBl ZXJzJyBtb2JpbGl0eS4NCg0KMi4yLjIuICBDaHVybiBvZiB0aGUgb3ZlcmxheQ0KDQogICBDb25z aWRlcmluZyBzaXAgdXNlcnMnIG1vYmlsaXR5IGluIHdpcmVsZXNzIGFjY2VzcyBuZXR3b3JrDQog ICBlbnZpcm9ubWVudCwgdGhlcmUgd291bGQgYmUgbW9yZSBwcm9iYWJpbGl0eSBmb3IgcGVlcnMn IGpvaW5pbmcsDQogICBsZWF2aW5nIG9mIHRoZSBvdmVybGF5IHdoaWNoIGhhcyBpbXBhY3Qgb24g dGhlIGNodXJuIG9mIHRoZSBvdmVybGF5Lg0KICAgRnVydGhlciwgcGVlcnMgY2FuIGJlIG1vcmUg ZWFzaWx5IHRvIGxvc2UgaXRzIGNvbm5lY3Rpb24gYmVmb3JlDQogICBzZW5kaW5nIExlYXZlIG1l c3NhZ2UgaW4gc3VjaCB3aXJlbGVzcyBlbnZpcm9ubWVudC4gIEFuZCB0aGlzIHdpbGwNCiAgIG1h a2UgdGhlIGRhdGEgc3RvcmVkIGluIHRoZSBwZWVycyB1bnJlYWNoYWJsZS4NCg0KICAgSWYgd2Ug bWFrZSBtb2JpbGUgc2lwIHVzZXIganVzdCBjbGllbnQgb2YgdGhlIG92ZXJsYXksIHRoZXJlIHdv dWxkDQogICBub3QgYmUgc3VjaCBwcm9ibGVtLg0KDQoyLjMuICBFeGNsdXNpdml0eSB0b3dhcmRz IG92ZXJsYXkgY2xpZW50cyBpbiBzaXAgdXNhZ2UNCg0KICAgRXhjbHVzaXZpdHkgdG93YXJkcyBv dmVybGF5IGNsaWVudHMgaW4gc2lwIHVzYWdlIHdvdWxkIGhhdmUNCiAgIHJlc3RyaWN0aW9uIG9u IG9wZXJhdGluZyB3YXkgZm9yIG92ZXJsYXkgbmV0d29yayBvcGVyYXRvcnMuDQoNCg0KDQoNCg0K DQoNCg0KR2FvICYgTWVuZyAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDIyLCAyMDEwICAg ICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEEgTmV3IFNJ UCBVc2FnZSBmb3IgUkVMT0FEICAgICAgICAgICAgICBKdWx5IDIwMDkNCg0KDQozLiAgVGhlIG5l dyBzb2x1dGlvbg0KDQogICBUaGUgbWFpbiBkaWZmZXJlbmNlIGlzIHRoYXQgc2lwIHVzZXIgcmVn aXN0ZXJzIGhpcyBhZGRyZXNzIHdoaWxlIG5vdA0KICAgTm9kZUlELCB1bmRlciBoaXMgQU9SLg0K DQozLjEuICBTb2x1dGlvbiBpbnRyb2R1Y3Rpb24NCg0KICAgVGhlIHByb2Nlc3Mgb2YgYSBzaXAg Y2FsbDoNCg0KICAgMS4gIENhbGxlZSBzdG9yZXMgYSBtYXBwaW5nIGZyb20gaGlzIFVSSSB0byBo aXMgTm9kZS1JRCBpbiB0aGUNCiAgIG92ZXJsYXkuICBBbmQgdGhlIE5vZGVJRCBvZiB0aGUgcGVl ciBjaG9vc2VkIHRvIHN0b3JlIHRoZSBtYXBwaW5nIGhhcw0KICAgaGFzaCByZWxhdGlvbnNoaXAg d2l0aCBjYWxsZWUncyBVUkkuDQoNCiAgIDIuICBDYWxsZXIgbG9va3MgdXAgY2FsbGVlJ3MgVVJJ IGluIHRoZSBvdmVybGF5IGFuZCByZXRyaWV2ZXMNCiAgIGNhbGxlZSdzIGFkZHJlc3MuDQoNCiAg IDMuICBDYWxsZXIgdXNlcyBJQ0UncyBvZmZlci9hbnN3ZXIgdG8gZXhjaGFuZ2UgY2FsbGVyJ3Mg YW5kIGNhbGxlZSdzDQogICBjYW5kaWRhdGUgYWRkcmVzc2VzLg0KDQogICBUaGUgcHJvY2VzcyBv ZiBhIHNpcCBjYWxsDQoNCg0KICAgICAgQ2FsbGVyICAgICAgICAgICAgICBPdmVybGF5ICAgICAg ICAgICAgICAgIENhbGxlZQ0KICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0t LS0tLS0tLS0tLSBTdG9yZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAtLS0t LS0tLS0tLS0tLS0tLS0tPg0KICAgICAgRmV0Y2ggLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwt LS0tLS0tLS0tLS0tLS0tIEZldGNoDQoNCiAgICAgIElDRSBPZmZlciAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tIElDRSBBbnN3ZXINCiAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0gSUNFIENo ZWNrcyAtLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIElOVklURSAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gT0sNCiAgICAgIEFDSyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwtLS0tLS0tLS0tLS0gSUNFIENoZWNrcyBm b3IgbWVkaWEgLS0tLS0tLS0tLS0tLT4NCiAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLSBSVFAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgMQ0KDQozLjIuICBNb3JlIG1lcml0cw0KDQozLjIuMS4gIEhhbGYgc3BlbmRp bmcNCg0KICAgQWZ0ZXIgZmV0Y2hpbmcgdGhlIGNhbGxlZSdzIGFkZHJlc3MsIHRoZSBjYWxsZXIg Y2FuIHVzaW5nIElDRSBvZmZlci8NCiAgIGFuc3dlciBwcm9jZWR1cmUgZGlyZWN0bHksIHdpdGhv dXQgQXBwQXR0YWNoIHByb2NlZHVyZSBpbiB0aGUNCiAgIG92ZXJsYXkuDQoNCg0KDQpHYW8gJiBN ZW5nICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjIsIDIwMTAgICAgICAgICAgICAgICAg W1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgQSBOZXcgU0lQIFVzYWdlIGZvciBS RUxPQUQgICAgICAgICAgICAgIEp1bHkgMjAwOQ0KDQoNCjMuMi4yLiAgU3VwcG9ydGluZyBjbGll bnRzJyBtb2JpbGl0eSBpbmhlcmVudGx5DQoNCiAgIFdoZW4gY2FsbGVlIGNoYW5nZXMgaXRzIGFk ZHJlc3MsIGl0IGNhbiBzZW5kIGEgbmV3IHJlZ2lzdGVyaW5nDQogICBtZXNzYWdlIHRvIG92ZXJs YXkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KR2FvICYgTWVuZyAgICAg ICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDIyLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDZd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEEgTmV3IFNJUCBVc2FnZSBmb3IgUkVMT0FEICAg ICAgICAgICAgICBKdWx5IDIwMDkNCg0KDQo0LiAgTm9ybWF0aXZlIHJlZmVyZW5jZXMNCg0KICAg W0ktRC5pZXRmLW1tdXNpYy1pY2VdDQogICAgICAgICAgICAgIFJvc2VuYmVyZywgSi4sICJJbnRl cmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudA0KICAgICAgICAgICAgICAoSUNFKTog QSBQcm90b2NvbCBmb3IgTmV0d29yayBBZGRyZXNzICBUcmFuc2xhdG9yIChOQVQpDQogICAgICAg ICAgICAgIFRyYXZlcnNhbCBmb3IgT2ZmZXIvQW5zd2VyIFByb3RvY29scyIsDQogICAgICAgICAg ICAgIGRyYWZ0LWlldGYtbW11c2ljLWljZS0xOSAod29yayBpbiBwcm9ncmVzcyksIE9jdG9iZXIg MjAwNy4NCg0KICAgW0ktRC5pZXRmLXAycHNpcC1iYXNlXQ0KICAgICAgICAgICAgICBKZW5uaW5n cywgQy4sIExvd2VrYW1wLCBCLiwgUmVzY29ybGEsIEUuLCBCYXNldCwgUy4sIGFuZA0KICAgICAg ICAgICAgICBILiBTY2h1bHpyaW5uZSwgIlJFc291cmNlIExPY2F0aW9uIEFuZCBEaXNjb3Zlcnkg KFJFTE9BRCkNCiAgICAgICAgICAgICAgQmFzZSBQcm90b2NvbCIsIGRyYWZ0LWlldGYtcDJwc2lw LWJhc2UtMDMgKHdvcmsgaW4NCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBKdWx5IDIwMDkuDQoN CiAgIFtJLUQuaWV0Zi1wMnBzaXAtc2lwXQ0KICAgICAgICAgICAgICBKZW5uaW5ncywgQy4sIExv d2VrYW1wLCBCLiwgUmVzY29ybGEsIEUuLCBCYXNldCwgUy4sIGFuZA0KICAgICAgICAgICAgICBI LiBTY2h1bHpyaW5uZSwgIkEgU0lQIFVzYWdlIGZvciBSRUxPQUQiLA0KICAgICAgICAgICAgICBk cmFmdC1pZXRmLXAycHNpcC1zaXAtMDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDA5Lg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KR2FvICYgTWVuZyAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDIyLCAyMDEw ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIEEgTmV3 IFNJUCBVc2FnZSBmb3IgUkVMT0FEICAgICAgICAgICAgICBKdWx5IDIwMDkNCg0KDQpBdXRob3Jz JyBBZGRyZXNzZXMNCg0KICAgR2FvIHlhbmcNCiAgIFpURQ0KICAgQ0hJTkENCg0KICAgRW1haWw6 IGdhby55YW5nMkB6dGUuY29tLmNuDQoNCg0KICAgTWVuZyBZdQ0KICAgWlRFDQogICBDSElOQQ0K DQogICBFbWFpbDogbWVuZy55dUB6dGUuY29tLmNuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkdhbyAmIE1l bmcgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyMiwgMjAxMCAgICAgICAgICAgICAgICBb UGFnZSA4XQ0KDA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAg ICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTEN CiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAg ICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjEx DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFp biBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4N ClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpU RSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 003A20E6482575FA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB0aGluayBpdCBp cyBzaWduaWZpY2F0aXZlIHRvIHRhbGsNCnRoZSB0b3BpYyBiZWZvcmUgdGhlIHRoZSB1cGxvYWQg cmVvcGVubmluZyBkYXRlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+VGhlIGFjY2Vzc29yeSBpcyB0aGUgZHJhZnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWVsIGZyZWUgZm9yIGRpc2N1c3Npb24uPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnAycHNpcCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO1kuIEdhbzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW50ZXJuZXQtRHJhZnQgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClkuIE1lbmc8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkludGVuZGVkIHN0YXR1 czogU3RhbmRhcmRzIFRyYWNrICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWlRFPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5FeHBpcmVzOiBKYW51YXJ5IDIyLCAyMDEwICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0p1 bHkgMjEsIDIwMDk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0EgTmV3IFNJUCBVc2FnZSBmb3Ig UkVMT0FEPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO2RyYWZ0LWdh b3lhbmctcDJwc2lwLW5ldy1zaXAtdXNhZ2UtMDAudHh0PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TdGF0dXMgb2YgdGhpcyBNZW1vPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7VGhpcyBJ bnRlcm5ldC1EcmFmdCBpcw0Kc3VibWl0dGVkIHRvIElFVEYgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwO3Byb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZA0KQkNQIDc5LiAmbmJzcDtUaGlzIGRvY3Vt ZW50IG1heSBub3QgYmUgbW9kaWZpZWQsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YW5kIGRlcml2YXRpdmUgd29ya3Mgb2YNCml0IG1heSBu b3QgYmUgY3JlYXRlZCwgYW5kIGl0IG1heSBub3QgYmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtwdWJsaXNoZWQgZXhjZXB0IGFzIGFuDQpJ bnRlcm5ldC1EcmFmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcNCmRvY3VtZW50 cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtUYXNrIEZvcmNlIChJRVRGKSwgaXRzDQphcmVh cywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gJm5ic3A7Tm90ZSB0aGF0PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7b3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGUNCndvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LTwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0RyYWZ0cy48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDtJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0DQpkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4 aW11bSBvZiBzaXggbW9udGhzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7YW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwNCm9yIG9ic29s ZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7dGltZS4gJm5ic3A7SXQgaXMgaW5hcHByb3By aWF0ZQ0KdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDttYXRlcmlhbCBvciB0byBj aXRlIHRoZW0NCm90aGVyIHRoYW4gYXMgJnF1b3Q7d29yayBpbiBwcm9ncmVzcy4mcXVvdDs8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDtUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cw0KY2FuIGJlIGFjY2Vzc2VkIGF0 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 aHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1RoZSBsaXN0 IG9mIEludGVybmV0LURyYWZ0DQpTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtUaGlzIEludGVybmV0LURyYWZ0 IHdpbGwNCmV4cGlyZSBvbiBKYW51YXJ5IDIyLCAyMDEwLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q29weXJpZ2h0IE5vdGljZTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0NvcHlyaWdo dCAoYykgMjAwOSBJRVRGDQpUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtk b2N1bWVudCBhdXRob3JzLiAmbmJzcDtBbGwNCnJpZ2h0cyByZXNlcnZlZC48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtUaGlzIGRv Y3VtZW50IGlzIHN1YmplY3QNCnRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1By b3Zpc2lvbnMgUmVsYXRpbmcgdG8NCklFVEYgRG9jdW1lbnRzIGluIGVmZmVjdCBvbiB0aGUgZGF0 ZSBvZjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwO3B1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQNCihodHRwOi8vdHJ1c3RlZS5pZXRmLm9y Zy9saWNlbnNlLWluZm8pLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwO1BsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQpjYXJlZnVsbHks IGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDthbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVj dA0KdG8gdGhpcyBkb2N1bWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbyAmYW1w OyBNZW5nICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtF eHBpcmVzIEphbnVhcnkgMjIsIDIwMTAgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbUGFnZSAxXTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+DDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+SW50ZXJuZXQtRHJhZnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyBBIE5ldyBT SVAgVXNhZ2UgZm9yIFJFTE9BRCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7SnVseSAyMDA5PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5BYnN0cmFjdDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgcG9pbnRzIG91 dA0KdGhlIG1haW4gZHJhd2JhY2tzIG9mIHRoZSBzb2x1dGlvbiBpbjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyZxdW90O2RyYWZ0LWlldGYt cDJwc2lwLXNpcC0wMSZxdW90Oy4NCiZuYnNwO0FuZCBzb2x2ZSBzdWNoIHByb2JsZW1zIGJ5IGlu dHJvZHVjaW5nIGE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDtuZXcgd2F5LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+VGFibGUgb2YgQ29udGVudHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsxLiAmbmJzcDtJbnRyb2R1 Y3Rpb24gJm5ic3A7Lg0KLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwOzIuICZuYnNwO01haW4gZHJhd2JhY2tzDQpvZiB0aGUgY3VycmVudCBzb2x1dGlvbiAm bmJzcDsuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzIuMS4gJm5ic3A7SGlkZGVuDQp0 cm91YmxlIGluIGludGVyLWRvbWFpbiBpbnRlcndvcmtpbmcgLiAuIC4gLiAuIC4gLiAuIDQ8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7Mi4yLiAmbmJzcDtIaWRkZW4NCnRyb3VibGUgaW4gc2lwIHVzZXJzJyBtb2JpbGl0eSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Mi4yLjEuICZuYnNwO0NvbXBlbGxpbmcN CnN1cHBvcnQgZm9yIHBlZXJzJyBtb2JpbGl0eSAmbmJzcDsuIC4gLiAuIC4gLiAuIC4gNDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Mi4yLjIuICZuYnNwO0NodXJuDQpvZiB0aGUgb3ZlcmxheSAmbmJzcDsuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsyLjMuICZuYnNwO0V4Y2x1c2l2aXR5 DQp0b3dhcmRzIG92ZXJsYXkgY2xpZW50cyBpbiBzaXAgdXNhZ2UgJm5ic3A7LiAuIC4gLiAuIDQ8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsz LiAmbmJzcDtUaGUgbmV3IHNvbHV0aW9uDQombmJzcDsuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDszLjEuICZuYnNwO1NvbHV0aW9uDQppbnRyb2R1 Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzMuMi4g Jm5ic3A7TW9yZQ0KbWVyaXRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzMuMi4xLiAmbmJzcDtIYWxmDQpzcGVuZGluZyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszLjIu Mi4gJm5ic3A7U3VwcG9ydGluZw0KY2xpZW50cycgbW9iaWxpdHkgaW5oZXJlbnRseSAuIC4gLiAu IC4gLiAuIC4gNjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOzQuICZuYnNwO05vcm1hdGl2ZSByZWZlcmVuY2VzDQombmJzcDsuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7QXV0aG9ycycgQWRkcmVzc2VzICZuYnNw Oy4NCi4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA4PC9mb250 Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW8gJmFtcDsgTWVuZyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5 IDIyLCAyMDEwICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7W1BhZ2UgMl08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPgw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkludGVybmV0 LURyYWZ0ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgQSBOZXcgU0lQIFVzYWdlIGZvciBS RUxPQUQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0p1 bHkgMjAwOTwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+MS4gJm5ic3A7SW50cm9kdWN0aW9uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7QXMgZGVzY3JpYmVkIGluICZxdW90O2Ry YWZ0LWlldGYtcDJwc2lwLXNpcC0wMSZxdW90OywNClJFTE9BRCdzIG9ubHkgcm9sZSBpbiBzaXA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDt1 c2FnZSBpcyB0byBzZXQgdXAgdGhlDQpkaXJlY3QgU0lQIGNvbm5lY3Rpb24gYmV0d2VlbiBjYWxs ZXIgYW5kPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7Y2FsbGVlLiAmbmJzcDtTbywgdGhlIHNpcA0KdXNlcnMgYXJlIG1vcmUgbGlrZSBjbGll bnRzIHRoYW4gcGVlcnMgaGVyZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtCdXQgJnF1b3Q7ZHJhZnQtaWV0Zi1wMnBzaXAtc2lwLTAxJnF1 b3Q7DQpyZXN0cmljdHMgdGhhdCBjYWxsZXIgYW5kIGNhbGxlZSBhcmU8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtwZWVycyBvZiB0aGUgb3Zl cmxheS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDtNYWtpbmcgYmFkIHRoaW5nIHdvcnNlLA0KY2FsbGVlIE1VU1QgYmUgcGVlcnMg b2YgdGhlIG92ZXJsYXkgd2hpbGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDt1c2luZyB0aGUgc29sdXRpb24gaW4gJnF1b3Q7ZHJhZnQtaWV0 Zi1wMnBzaXAtc2lwLTAxJnF1b3Q7Lg0KJm5ic3A7VGhlIHJlYXNvbiBpcyB0aGF0PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7b25seSBwZWVy cyBjYW4gYmUgcmVhY2hhYmxlDQpieSByb3V0aW5nIHRhYmxlIG9mIHRoZSBvdmVybGF5LjwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvICZh bXA7IE1lbmcgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0V4cGlyZXMgSmFudWFyeSAyMiwgMjAxMCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDNdPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4MPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5JbnRlcm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEEgTmV3 IFNJUCBVc2FnZSBmb3IgUkVMT0FEICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDtKdWx5IDIwMDk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuICZuYnNwO01haW4gZHJhd2JhY2tzIG9mIHRoZSBjdXJy ZW50DQpzb2x1dGlvbjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Mi4xLiAmbmJzcDtIaWRkZW4gdHJvdWJsZSBpbiBpbnRlci1kb21haW4NCmludGVyd29y a2luZzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwO0NvbnNpZGVyaW5nIGludGVyLWRvbWFpbg0KaW50ZXJ3b3JraW5nLCBjYWxsZXIg Y2FuIGJlIHVzZXIgb2Ygb3RoZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtkb21haW4uICZuYnNwO0lmIHdlIHVzZQ0KdGhlIHNvbHV0aW9u IGluICZxdW90O2RyYWZ0LWlldGYtcDJwc2lwLXNpcC0wMSZxdW90OywgdGhlcmU8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtzaG91bGQgYmUg YSBub2RlIGluIHRoZQ0Kb3RoZXIgZG9tYWluIGFzIHBlZXIgb2YgY2FsbGVlJ3Mgb3ZlcmxheS48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtU aGF0IGlzIG5vdCBhY2NlcHRhYmxlDQpmb3Igb3ZlcmxheSBuZXR3b3JraW5nIG9wZXJhdGluZywg YXMgc3RvcmluZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwO2RhdGEgaW4gb3RoZXIgZG9tYWluJ3MNCm5vZGUgY2FuIGJlIG5pZ2h0bWFyZS48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDtJZiB3ZSBtYWtlIHNpcCB1c2VycyBvdXRzaWRlDQpvZiB0aGUgb3ZlcmxheSBqdXN0IGNs aWVudHMsIHRoZXJlIHdvdWxkPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7bm90IGJlIHN1Y2ggcHJvYmxlbS4gJm5ic3A7SW4NCmZhY3QsIG1h a2luZyBjYWxsZXIganVzdCBjbGllbnQgb2YgdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7b3ZlcmxheSBjYW4gZ2V0IHJpZCBvZg0KdGhp cyBwcm9ibGVtLiAmbmJzcDtTbywgJnF1b3Q7ZHJhZnQtaWV0Zi1wMnBzaXAtc2lwLTAxJnF1b3Q7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 Y2FuIGFib2xpc2ggdGhlIHJlc3RyaWN0aW9uDQpvZiBjYWxsZXIgYXMgcGVlci48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtXaGF0 IG5lZWQgdG8gYmUgbWVudGlvbmVkDQppcyB0aGF0IHNpcCB1c2VycyBpbnNpZGUgdGhlIG92ZXJs YXkgY2FuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7cmVnaXN0ZXIgaXRzZWxmIGZyb20gcGVlcnMNCm9mIHRoZSBvdmVybGF5IG9yIGZyb20g Y2xpZW50cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PjIuMi4gJm5ic3A7SGlkZGVuIHRyb3VibGUgaW4gc2lwIHVzZXJzJw0KbW9iaWxpdHk8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuMi4xLiAmbmJzcDtD b21wZWxsaW5nIHN1cHBvcnQgZm9yDQpwZWVycycgbW9iaWxpdHk8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtBcyBzaXAgdXNlcnMg YXJlIHBlZXJzLA0Kc28gdGhlIG92ZXJsYXkgY29tcGVsbHMgdGhlIHN1cHBvcnQgb2YgcGVlcnMn PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 bW9iaWxpdHkuICZuYnNwO0lmIHdlIG1ha2UNCnNpcCB1c2VyIGp1c3QgY2xpZW50IG9mIHRoZSBv dmVybGF5LCB0aGVyZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwO3dvdWxkIG5vdCBiZSBzdWNoIHByb2JsZW0uDQombmJzcDtJdCBtZWFucyB0 aGF0IHdlIGNhbiBjb25zdHJ1Y3QgYW4gb3ZlcmxheTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3N1cHBvcnRpbmcgY2xpZW50cycgbW9iaWxp dHkNCndpdGhvdXQgbmVlZGluZyBwZWVycycgbW9iaWxpdHkuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yLjIuMi4gJm5ic3A7Q2h1cm4gb2YgdGhlIG92 ZXJsYXk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDtDb25zaWRlcmluZyBzaXAgdXNlcnMnDQptb2JpbGl0eSBpbiB3aXJlbGVzcyBh Y2Nlc3MgbmV0d29yazwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwO2Vudmlyb25tZW50LCB0aGVyZSB3b3VsZA0KYmUgbW9yZSBwcm9iYWJpbGl0 eSBmb3IgcGVlcnMnIGpvaW5pbmcsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7bGVhdmluZyBvZiB0aGUgb3ZlcmxheQ0Kd2hpY2ggaGFzIGlt cGFjdCBvbiB0aGUgY2h1cm4gb2YgdGhlIG92ZXJsYXkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7RnVydGhlciwgcGVlcnMgY2FuIGJlIG1v cmUNCmVhc2lseSB0byBsb3NlIGl0cyBjb25uZWN0aW9uIGJlZm9yZTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3NlbmRpbmcgTGVhdmUgbWVz c2FnZSBpbg0Kc3VjaCB3aXJlbGVzcyBlbnZpcm9ubWVudC4gJm5ic3A7QW5kIHRoaXMgd2lsbDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO21h a2UgdGhlIGRhdGEgc3RvcmVkIGluDQp0aGUgcGVlcnMgdW5yZWFjaGFibGUuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7SWYgd2Ug bWFrZSBtb2JpbGUgc2lwIHVzZXINCmp1c3QgY2xpZW50IG9mIHRoZSBvdmVybGF5LCB0aGVyZSB3 b3VsZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwO25vdCBiZSBzdWNoIHByb2JsZW0uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4yLjMuICZuYnNwO0V4Y2x1c2l2aXR5IHRvd2FyZHMgb3ZlcmxheQ0K Y2xpZW50cyBpbiBzaXAgdXNhZ2U8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtFeGNsdXNpdml0eSB0b3dhcmRzIG92ZXJsYXkNCmNs aWVudHMgaW4gc2lwIHVzYWdlIHdvdWxkIGhhdmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtyZXN0cmljdGlvbiBvbiBvcGVyYXRpbmcNCndh eSBmb3Igb3ZlcmxheSBuZXR3b3JrIG9wZXJhdG9ycy48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkdhbyAmYW1wOyBNZW5nICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtFeHBpcmVzIEphbnVhcnkgMjIsIDIwMTAgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbUGFnZSA0XTwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+DDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW50ZXJuZXQtRHJhZnQgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyBBIE5ldyBTSVAgVXNhZ2UgZm9yIFJFTE9BRCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7SnVseSAyMDA5PC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4zLiAmbmJzcDtUaGUgbmV3IHNv bHV0aW9uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7VGhlIG1haW4gZGlmZmVyZW5jZSBpcw0KdGhhdCBzaXAgdXNlciByZWdpc3Rl cnMgaGlzIGFkZHJlc3Mgd2hpbGUgbm90PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Tm9kZUlELCB1bmRlciBoaXMgQU9SLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+My4xLiAmbmJzcDtTb2x1dGlv biBpbnRyb2R1Y3Rpb248L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtUaGUgcHJvY2VzcyBvZiBhIHNpcCBjYWxsOjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzEuICZu YnNwO0NhbGxlZSBzdG9yZXMNCmEgbWFwcGluZyBmcm9tIGhpcyBVUkkgdG8gaGlzIE5vZGUtSUQg aW4gdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7b3ZlcmxheS4gJm5ic3A7QW5kIHRoZQ0KTm9kZUlEIG9mIHRoZSBwZWVyIGNob29zZWQg dG8gc3RvcmUgdGhlIG1hcHBpbmcgaGFzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7aGFzaCByZWxhdGlvbnNoaXAgd2l0aA0KY2FsbGVlJ3Mg VVJJLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOzIuICZuYnNwO0NhbGxlciBsb29rcyB1cA0KY2FsbGVlJ3MgVVJJIGluIHRoZSBv dmVybGF5IGFuZCByZXRyaWV2ZXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtjYWxsZWUncyBhZGRyZXNzLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzMuICZuYnNwO0NhbGxl ciB1c2VzIElDRSdzDQpvZmZlci9hbnN3ZXIgdG8gZXhjaGFuZ2UgY2FsbGVyJ3MgYW5kIGNhbGxl ZSdzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7Y2FuZGlkYXRlIGFkZHJlc3Nlcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtUaGUgcHJvY2VzcyBvZiBhIHNpcCBjYWxsPC9m b250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyBDYWxsZXIgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO092ZXJsYXkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDtDYWxsZWU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZsdDstLS0tLS0tLS0tLS0tLS0tLS0tDQpTdG9yZTwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7U3RvcmUgLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IEZldGNo IC0tLS0tLS0tLS0tLS0tLS0mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7LS0tLS0tLS0tLS0tLS0tLQ0KRmV0Y2g8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgJm5ic3A7IElDRSBPZmZlciAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpJQ0UgQW5zd2VyPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tDQpJQ0UgQ2hlY2tzIC0t LS0tLS0tLS0tLS0tLS0tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSU5WSVRFIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT0s8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IEFDSyAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDstLS0tLS0tLS0tLS0NCklD RSBDaGVja3MgZm9yIG1lZGlhIC0tLS0tLS0tLS0tLS0mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7LS0tLS0tLS0t LS0tLS0tLS0tLS0NClJUUCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0OzwvZm9udD4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWd1cmUNCjE8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuMi4gJm5i c3A7TW9yZSBtZXJpdHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjMuMi4xLiAmbmJzcDtIYWxmIHNwZW5kaW5nPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7QWZ0ZXIgZmV0Y2hpbmcgdGhl IGNhbGxlZSdzDQphZGRyZXNzLCB0aGUgY2FsbGVyIGNhbiB1c2luZyBJQ0Ugb2ZmZXIvPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YW5zd2Vy IHByb2NlZHVyZSBkaXJlY3RseSwNCndpdGhvdXQgQXBwQXR0YWNoIHByb2NlZHVyZSBpbiB0aGU8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtv dmVybGF5LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+R2FvICZhbXA7IE1lbmcgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0V4cGlyZXMgSmFudWFyeSAyMiwgMjAxMCAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDVdPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4MPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbnRlcm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7IEEgTmV3IFNJUCBVc2FnZSBmb3IgUkVMT0FEICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtKdWx5IDIwMDk8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuMi4yLiAmbmJzcDtTdXBw b3J0aW5nIGNsaWVudHMnIG1vYmlsaXR5DQppbmhlcmVudGx5PC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7V2hlbiBjYWxsZWUgY2hh bmdlcyBpdHMNCmFkZHJlc3MsIGl0IGNhbiBzZW5kIGEgbmV3IHJlZ2lzdGVyaW5nPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bWVzc2FnZSB0 byBvdmVybGF5LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvICZh bXA7IE1lbmcgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0V4cGlyZXMgSmFudWFyeSAyMiwgMjAxMCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDZdPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4MPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5JbnRlcm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEEgTmV3 IFNJUCBVc2FnZSBmb3IgUkVMT0FEICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDtKdWx5IDIwMDk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjQuICZuYnNwO05vcm1hdGl2ZSByZWZlcmVuY2VzPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 W0ktRC5pZXRmLW1tdXNpYy1pY2VdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 IFJvc2VuYmVyZywgSi4sICZxdW90O0ludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2ht ZW50PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IChJQ0UpOiBBIFByb3RvY29s IGZvciBOZXR3b3JrIEFkZHJlc3MgJm5ic3A7VHJhbnNsYXRvciAoTkFUKTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyBUcmF2ZXJzYWwgZm9yIE9mZmVyL0Fuc3dlciBQcm90b2Nv bHMmcXVvdDssPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IGRyYWZ0LWlldGYt bW11c2ljLWljZS0xOSAod29yayBpbiBwcm9ncmVzcyksIE9jdG9iZXIgMjAwNy48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtbSS1E LmlldGYtcDJwc2lwLWJhc2VdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEpl bm5pbmdzLCBDLiwgTG93ZWthbXAsIEIuLCBSZXNjb3JsYSwgRS4sIEJhc2V0LCBTLiwgYW5kPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEguIFNjaHVsenJpbm5lLCAmcXVvdDtS RXNvdXJjZSBMT2NhdGlvbiBBbmQgRGlzY292ZXJ5IChSRUxPQUQpPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7IEJhc2UgUHJvdG9jb2wmcXVvdDssIGRyYWZ0LWlldGYtcDJwc2lw LWJhc2UtMDMgKHdvcmsgaW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgcHJv Z3Jlc3MpLCBKdWx5IDIwMDkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7W0ktRC5pZXRmLXAycHNpcC1zaXBdPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEplbm5pbmdzLCBDLiwgTG93ZWthbXAsIEIuLCBSZXNj b3JsYSwgRS4sIEJhc2V0LCBTLiwgYW5kPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7IEguIFNjaHVsenJpbm5lLCAmcXVvdDtBIFNJUCBVc2FnZSBmb3IgUkVMT0FEJnF1b3Q7LDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyBkcmFmdC1pZXRmLXAycHNpcC1zaXAt MDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDA5LjwvZm9udD4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvICZhbXA7 IE1lbmcgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0V4 cGlyZXMgSmFudWFyeSAyMiwgMjAxMCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDddPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4MPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5JbnRlcm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEEgTmV3IFNJ UCBVc2FnZSBmb3IgUkVMT0FEICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDtKdWx5IDIwMDk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkF1dGhvcnMnIEFkZHJlc3NlczwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0dhbyB5YW5nPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7WlRFPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Q0hJ TkE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDtFbWFpbDogZ2FvLnlhbmcyQHp0ZS5jb20uY248L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtNZW5nIFl1PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7WlRF PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 Q0hJTkE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDtFbWFpbDogbWVuZy55dUB6dGUuY29tLmNuPC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5HYW8gJmFtcDsgTWVuZyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5IDIyLCAyMDEwICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W1BhZ2UgOF08 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPgw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVs ICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4Nzcy MTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQog WmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8 YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8u eWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PC9mb250Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZu YnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5 Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtU aGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlh bC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29i bGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7 YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3Ro ZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7 ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2Nv bmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5i c3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3Im bmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRk cmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhp cyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZu YnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5i c3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJz cDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDti eSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 003A20E6482575FA_=-- From softgear@etri.re.kr Tue Jul 21 17:11:18 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7CB3A6B9D for ; Tue, 21 Jul 2009 17:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.597 X-Spam-Level: X-Spam-Status: No, score=-98.597 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, HELO_MISMATCH_INFO=1.448, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ3KqJrzObWB for ; Tue, 21 Jul 2009 17:11:18 -0700 (PDT) Received: from email2.etri.info (email2.etri.re.kr [129.254.16.132]) by core3.amsl.com (Postfix) with ESMTP id B96BF3A6DF1 for ; Tue, 21 Jul 2009 17:11:17 -0700 (PDT) Received: from SOFTGEAR ([129.254.232.20]) by email2.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jul 2009 09:11:17 +0900 From: "Softgear Ko" To: References: In-Reply-To: Date: Wed, 22 Jul 2009 09:11:34 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoKW8D+H05nMt7yQCe1skrf/z6EVwABRhSg Content-Language: ko x-cr-hashedpuzzle: 3Jo= BBej CVPQ D7Pn D/Vj E7tp GRvj Grr3 HEdT H3YH H9BA H+lm I/ed JMXw JhWv Jt3f; 1; cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {846D7473-E179-46EF-82B5-2987D370D96E}; cwBvAGYAdABnAGUAYQByAEAAZQB0AHIAaQAuAHIAZQAuAGsAcgA=; Wed, 22 Jul 2009 00:11:32 GMT; bgBlAHcAIAB2AGUAcgBzAGkAbwBuACAAbwBmACAASQBQAFQAVgAgAHUAcwBhAGcAZQAgAGYAbwByACAAUgBFAEwATwBBAEQA x-cr-puzzleid: {846D7473-E179-46EF-82B5-2987D370D96E} X-OriginalArrivalTime: 22 Jul 2009 00:11:17.0574 (UTC) FILETIME=[EEF65660:01CA0A60] Subject: [P2PSIP] new version of IPTV usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 00:11:18 -0000 Dear all, I have submitted new version of IPTV usage for RELOAD. http://tools.ietf.org/html/draft-softgear-p2psip-iptv-01 Abstract This document defines a P2P IPTV Usage for Resource Location And Discovery (RELOAD). The IPTV Usage provides the functionality of IPTV servers in a fully-distributed system using P2PSIP RELOAD. The IPTV Usage provides the metadata storage, channel peer list storage, and channel peer group storage using the P2PSIP overlay. There are still many typos and open issues. Any comments are welcome. - Softgear Ko @ ETRI. From Even.roni@huawei.com Wed Jul 22 00:41:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB5A3A6B8B for ; Wed, 22 Jul 2009 00:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.975 X-Spam-Level: X-Spam-Status: No, score=0.975 tagged_above=-999 required=5 tests=[AWL=1.470, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYnX5AVN2Gl9 for ; Wed, 22 Jul 2009 00:41:05 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F2FFA3A692D for ; Wed, 22 Jul 2009 00:41:03 -0700 (PDT) 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 <0KN600FBUAD4FQ@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 22 Jul 2009 15:34:16 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN6004LRAD4A3@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 22 Jul 2009 15:34:16 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-117-31.red.bezeqint.net [79.181.117.31]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN600MMIACXYQ@szxml01-in.huawei.com>; Wed, 22 Jul 2009 15:34:16 +0800 (CST) Date: Wed, 22 Jul 2009 10:33:04 +0300 From: Roni Even In-reply-to: To: 'Bruce Lowekamp' Message-id: <04b401ca0a9e$aba135e0$02e3a1a0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcoE+gvQxAJJ4zq4QvqcXPB5f/JzJQFnQjcg References: <025b01c9fec9$489efb70$d9dcf250$%roni@huawei.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:41:07 -0000 Hi Bruce, Inline Roni > -----Original Message----- > From: Bruce Lowekamp [mailto:bbl@lowekamp.net] > Sent: Wednesday, July 15, 2009 6:06 AM > To: Roni Even > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02 > > I would like to see a couple changes in how the ideas in this draft > are implemented, but the concepts are basically sound. I would > support adopting this draft as an extension. > > Section 3 should probably reflect in its discussion that the DRR and > RPR responses require the establishment of a (D)TLS session before the > message is exchanged. I think a precise analysis of the cost isn't > necessary, but the diagrams are a bit misleading in how many messages > are involved. You are right that the responder needs to establish (D)TLS session. We can add text explaining the link layer behavior for the response. It can also be used to find out if DRR connectivity exists. > > In Section 5.2, why not implement IGNORE-STATE-KEEPING as a > ForwardingOption with FORWARD_CRITICAL? The WG can then discuss > whether to incorporate that into the base draft or leave it as an > extension. Parenthetically, the state to be concerned about is not so > much the hop-by-hop retransmission, but state that may be kept if the > peer is keeping per-transaction forwarding state rather than encoding > it in the via-list. I think that is what 5.2.1 says we will put the right language. The current text meant to have it in the forwarding option flags but the note asks if it should be specified in the forwarding option in the base draft. Maybe this should be discussed in a separate thread with reload base as the topic. I think that there are two questions here 1. Should this flag be part of forwarding option flags in base draft. There is no registry for the flags 2. Should this flag be part of forwarding header since it may have other uses. > > Also in 5.2, with the changes in the via list structure, I think we > need to revisit adding an IP address as a DestinationType in an > extension. I think the ForwardingOption works, but it smells a bit > too much like a hack to me. This may be a good solution for DRR but I am not sure if it will work for the relay peer case since the relay may be used only in the response. Also the peer that sends the response will not know who is the relay from the via/destination list and the relay need to know who is the final receiver. So there is a need to give the response path which is not defined in base draft. The use of the ForwardingOption is the way to extend the forwarding header. > > Bruce From bbl@lowekamp.net Wed Jul 22 05:26:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698563A6821 for ; Wed, 22 Jul 2009 05:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ULHaLeRX9vN for ; Wed, 22 Jul 2009 05:26:50 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 50BBE3A68F6 for ; Wed, 22 Jul 2009 05:26:50 -0700 (PDT) Received: by fxm18 with SMTP id 18so144815fxm.37 for ; Wed, 22 Jul 2009 05:24:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.107.135 with SMTP id b7mr398662fap.30.1248265497334; Wed, 22 Jul 2009 05:24:57 -0700 (PDT) In-Reply-To: <04b401ca0a9e$aba135e0$02e3a1a0$%roni@huawei.com> References: <025b01c9fec9$489efb70$d9dcf250$%roni@huawei.com> <04b401ca0a9e$aba135e0$02e3a1a0$%roni@huawei.com> Date: Wed, 22 Jul 2009 08:24:57 -0400 Message-ID: From: Bruce Lowekamp To: Roni Even Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Relay support in draft-jiang-p2psip-relay-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 12:26:51 -0000 On Wed, Jul 22, 2009 at 3:33 AM, Roni Even wrote: >> -----Original Message----- >> From: Bruce Lowekamp [mailto:bbl@lowekamp.net] >> >> In Section 5.2, why not implement IGNORE-STATE-KEEPING as a >> ForwardingOption with FORWARD_CRITICAL? =C2=A0The WG can then discuss >> whether to incorporate that into the base draft or leave it as an >> extension. =C2=A0Parenthetically, the state to be concerned about is not= so >> much the hop-by-hop retransmission, but state that may be kept if the >> peer is keeping per-transaction forwarding state rather than encoding >> it in the via-list. > > I think that is what 5.2.1 says we will put the right language. The curre= nt text meant to have it in the forwarding option flags but the note asks i= f it should be specified in the forwarding option in the base draft. > Maybe this should be discussed in a separate thread with reload base as t= he topic. I think that there are two questions here > 1. Should this flag be part of forwarding option flags in base draft. The= re is no registry for the flags > 2. Should this flag be part of forwarding header since it may have other = uses. I agree we need to have the discussion of where this is defined. I personally believe it should be an option rather than part of the header, but that's another issue for the WG to decide. We removed the flags from the header in -03 since we had no use for them. Obviously that's another issue where the WG can decide to add them back, but all of this can be implemented with Forwarding Options rather than flags. > >> >> Also in 5.2, with the changes in the via list structure, I think we >> need to revisit adding an IP address as a DestinationType in an >> extension. =C2=A0I think the ForwardingOption works, but it smells a bit >> too much like a hack to me. > > This may be a good solution for DRR but I am not sure if it will work for= the relay peer case since the relay may be used only in the response. Also= the peer that sends the response will not know who is the relay from the v= ia/destination list and the relay need to know who is the final receiver. S= o there is a need to give the response path which is not defined in base dr= aft. > The use of the ForwardingOption is the way to extend the forwarding heade= r. A requesting peer can preload the via-list with the relay peer and itself to ensure that the desired response path is followed. There does need to be a specification for a Forwarding Option that prevents on-path peers from adding their own entries to the via list. Whether that should be the state keeping or a separate option is an interesting question. Bruce From melodysong@huawei.com Wed Jul 22 18:39:37 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524B73A6C94; Wed, 22 Jul 2009 18:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.493 X-Spam-Level: * X-Spam-Status: No, score=1.493 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lahLp9Ic615f; Wed, 22 Jul 2009 18:39:36 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 601683A6405; Wed, 22 Jul 2009 18:39:36 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700M6WNZUHQ@szxga03-in.huawei.com>; Thu, 23 Jul 2009 09:26:18 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700I0ONZU6M@szxga03-in.huawei.com>; Thu, 23 Jul 2009 09:26:18 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN700DZYNZU0J@szxml06-in.huawei.com>; Thu, 23 Jul 2009 09:26:18 +0800 (CST) Date: Thu, 23 Jul 2009 09:26:18 +0800 From: Song Haibin To: decade@ietf.org Message-id: <002a01ca0b34$94a4e580$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoLNJRWCfupf79bT9KLUFLQHEknxg== Cc: ppsp@ietf.org, p2psip@ietf.org, alto@ietf.org Subject: [P2PSIP] DECADE Bar BOF X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 01:39:37 -0000 Dear all, The time poll result shows that most people will be available on Wednesday evening. So the DECADE Bar BOF will finally be held on Wednesday evening, from 8pm to 10pm. The place is Room 201. The draft agenda is as the following: 1. Agenda bash 5min 2. Problem statement Haibin Song 20min 3. Survey Ning Zong 30min 4. Sailor presentation Richard Alimi 20min 5. BrachCache presentation Yu-shun Wang 20min Welcome to join the meeting and lookforward to meeting you in Stockholm. Best Regards, Haibin Skype: alexsonghw From abcdmatao@gmail.com Thu Jul 23 01:14:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8EF3A693B for ; Thu, 23 Jul 2009 01:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4DNouxwGi2q for ; Thu, 23 Jul 2009 01:14:03 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id EB6B83A68ED for ; Thu, 23 Jul 2009 01:14:02 -0700 (PDT) Received: by gxk9 with SMTP id 9so1421810gxk.13 for ; Thu, 23 Jul 2009 01:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=DK8BFXYMEfoTG6/jaih4lrzxDQ7gT0OmvKuG3Ldspvw=; b=cvqPUko7psujh4yU+gWxfra7/+kNkcKqDYR9BgZz48Mfivr7rcd56H7QmIcHIEgv3K 6VuEG3WCoY6LwyI7Q2wDM/aa6+ZIPHxRtihKBiRBtxuychv9ZyD5KuFi4uNPON9u7nq4 b7YmPAcAI608detTMCHdvaomnAfskhjo0pdA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=e65XIlIqyWL2LR/wuEs5kVPC9clvrwWUwOeWgXLkpR/oDWDyPuPpPV9IVgGTGd56XW nq+eEQbD/8tGahDDlCCr22EJpbl/o/ac+jmTv07D6HZpQ0tH0xheh7uWa6EVgWX6vSOE fH/A50Re6C8WZ5sKPDSPmbPo8FjWKedePl6DA= MIME-Version: 1.0 Received: by 10.150.49.15 with SMTP id w15mr2660410ybw.50.1248336765144; Thu, 23 Jul 2009 01:12:45 -0700 (PDT) Date: Thu, 23 Jul 2009 16:12:45 +0800 Message-ID: <99978d7d0907230112w74f2a589rce7605902b34a24f@mail.gmail.com> From: Tao Ma To: llf.bbi001@gmail.com, p2psip@ietf.org Content-Type: multipart/alternative; boundary=000e0cd6aa2e724fc2046f5b0dfd Cc: standardMINE@googlegroups.com Subject: Re: [P2PSIP] p2psip-hierachical-p2psip-overlay X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 08:14:03 -0000 --000e0cd6aa2e724fc2046f5b0dfd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I have read the draft. I think the idea of considering node heterogeneity and applying it to improve system scalability and service availability is of significance. But I have some doubts on the classification of sub-overlays. In this draft, the node can join in a sub-overlay with the level corresponding to its capability. However, in the analysis of benefits of this architecture, I am not able to figure out how the scalability is reflected. Because the weak nodes are bottlenecks of the performace, how can they benefit from this architecture? I think there needs a contrastive analysis to show the performance advancement in the hierarchical architecture especially for the weak nodes. I would appreciate for your reply:) Tao Ma July 23rd Beijing University of Posts and Telecommunications, Mobile lIfe and New Media Lab --000e0cd6aa2e724fc2046f5b0dfd Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,
    I have read the draft. I think the idea of consid= ering node heterogeneity and applying  it to improve system scalabilit= y and service availability is of significance. But I have some doubts on th= e classification of sub-overlays. In this draft, the node can join in a sub= -overlay with the level corresponding to its capability. However, in the an= alysis of benefits of this architecture, I am not able to figure out how th= e scalability is reflected. Because the weak nodes are bottlenecks of the p= erformace,  how can they benefit from this architecture? I think there= needs a contrastive analysis to show the performance  advancement in = the hierarchical architecture especially for the weak nodes.
    I would appreciate for your reply:)
Tao Ma
=

July 23rd

Beijing University of Posts and Telecommunications, Mobile lIfe and New Media Lab


--000e0cd6aa2e724fc2046f5b0dfd-- From abcdmatao@gmail.com Thu Jul 23 01:44:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626473A6817 for ; Thu, 23 Jul 2009 01:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTeNevIiKDuL for ; Thu, 23 Jul 2009 01:44:24 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id 6D28C3A69D6 for ; Thu, 23 Jul 2009 01:44:24 -0700 (PDT) Received: by yxe34 with SMTP id 34so1411935yxe.29 for ; Thu, 23 Jul 2009 01:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=x6SbLdLoWR8e1+xRGyGxLBNoi37xumkphtwQ5dxm3kk=; b=cszRWZFm0jffwuEVVrUXqsKcb4VPBxHTd/jrUPywh3uyLlwihbjP5PVj1YqdLr062E WQSMj4EGChpQx1vkMsIF5GhnuujCIvzVP+48uShT1uAxeJm8BRFvc/7Gu7STuAl+vaPM 8FgPN7bBWq/VfxUY2b9vA1uj3FtQSaHW9Pbu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=vpXiNRA76dWCVO5dp1YB00EZTJE9lFBfeTYbeiAmXSzTjv1SDlZXZG8RW7tgfVfmyC GPvzhj+AXtXPndFQIdvGek1MaIImHKqZeC+s0gnyLPj8PSKf6P4n3XF/SK00B8pXpsLX zsG9qAzTM9eGu5g9k6hfD9nJDEC88zYXGNwj0= MIME-Version: 1.0 Received: by 10.150.211.20 with SMTP id j20mr2647940ybg.169.1248335360998; Thu, 23 Jul 2009 00:49:20 -0700 (PDT) Date: Thu, 23 Jul 2009 15:49:20 +0800 Message-ID: <99978d7d0907230049g129529ecoe2867cc3c183cbd3@mail.gmail.com> From: Tao Ma To: gaoyang2@zte.com.cn, p2psip@ietf.org Content-Type: multipart/alternative; boundary=000e0cd51dbac0bec7046f5ab918 Cc: standardMINE@googlegroups.com Subject: Re: [P2PSIP] A new proposal for SIP Usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 08:44:25 -0000 --000e0cd51dbac0bec7046f5ab918 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I have read the draft, which points out the drawbacks of draft-ietf-p2psip-sip-01. But I have some questions and confusion as follows: 1 You mentioned the exclusivity to overlay clients, but I don't think the draft-ietf-p2psip-sip-01 has explicitly excluded the client usage, whereas it doesn't mention the client support explicitly. Could you show me the apparent conflicts with the client usage in that draft? 2 I am a little confused about the description " The main difference is that sip user registers his address while not NodeID, under his AOR"in Section 3 "the new solution". Actually, client may have NodeID in RELOAD protocol. In the new solution why does the sip user register with address not NodeID? What does "address" here mean? 3 In Section 3.2.1, I am confused about the "half spending". You use ICE offer/answer, the draft-ietf-p2psip-sip-01 uses AppAttach mechanisms, how can you say your mechanism is "half spending"? I would appreciate for your reply:) Tao Ma July 23rd Beijing University of Posts and Telecommunications, Mobile lIfe and New mEdia Lab --000e0cd51dbac0bec7046f5ab918 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,
    I have read the draft, which points out the drawb= acks of draft-ietf-p2psip-sip-01. But I have some questions and confusion a= s follows:
    1 You mentioned the exclusivity to overlay= clients, but I don't think the draft-ietf-p2psip-sip-01 has explicitly= excluded the client usage, whereas it doesn't  mention the client= support explicitly. Could you show me the apparent conflicts with the clie= nt usage in that draft?
    2 I am a little confused about the description " The main difference is that sip user registers his= address while not NodeID, under his AOR"in Section 3 "the new solution". Actual= ly, client may have NodeID in RELOAD protocol. In the new solution why does= the sip user register with address not NodeID? What does "address&quo= t; here mean?
    3 In Section 3.2.1, I am confused about the "half s= pending". You use ICE offer/answer, the draft-ietf-p2psip-sip-01 uses = AppAttach mechanisms, how can you say your mechanism is "half spending= "?
    I would appreciate for your reply:)
Tao Ma
July 23= rd
Beijing University of Posts and Telecommunications, Mobile lIfe and N= ew mEdia Lab
--000e0cd51dbac0bec7046f5ab918-- From gao.yang2@zte.com.cn Thu Jul 23 01:46:43 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74473A6817 for ; Thu, 23 Jul 2009 01:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.828 X-Spam-Level: X-Spam-Status: No, score=-94.828 tagged_above=-999 required=5 tests=[AWL=-4.127, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJbN9anCuiOG for ; Thu, 23 Jul 2009 01:46:42 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4A6E03A69AF for ; Thu, 23 Jul 2009 01:46:42 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91102075036648; Thu, 23 Jul 2009 16:32:04 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 46629.3793157739; Thu, 23 Jul 2009 16:37:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6N8ieKC020241; Thu, 23 Jul 2009 16:44:41 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <99978d7d0907230050o3bb02cau4d3cf0f23b0d4cca@mail.gmail.com> To: Tao Ma MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 23 Jul 2009 16:44:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-23 16:44:29, Serialize complete at 2009-07-23 16:44:29 Content-Type: multipart/alternative; boundary="=_alternative 00300802482575FC_=" X-MAIL: mse2.zte.com.cn n6N8ieKC020241 Cc: p2psip@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogRndkOiBBIG5ldyBwcm9wb3NhbCBmb3IgU0lQ?= =?gb2312?b?IFVzYWdlIGZvciBSRUxPQUQ=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 08:46:44 -0000 This is a multipart message in MIME format. --=_alternative 00300802482575FC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkNvbW1lbnRzIGlubGluZS4NCg0KVGhhbmtzLg0KDQpHYW8NCg0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3 MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRl LmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNClRhbyBN YSA8YWJjZG1hdGFvQGdtYWlsLmNvbT4gDQoyMDA5LTA3LTIzIDE1OjUwDQoNCsrVvP7Iyw0KZ2Fv LnlhbmcyQHp0ZS5jb20uY24NCrOty80NCg0K1vfM4g0KRndkOiBbUDJQU0lQXUEgbmV3IHByb3Bv c2FsIGZvciBTSVAgVXNhZ2UgZm9yIFJFTE9BRA0KDQoNCg0KDQoNCkhpLA0KICAgIEkgaGF2ZSBy ZWFkIHRoZSBkcmFmdCwgd2hpY2ggcG9pbnRzIG91dCB0aGUgZHJhd2JhY2tzIG9mIA0KZHJhZnQt aWV0Zi1wMnBzaXAtc2lwLTAxLiBCdXQgSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFuZCBjb25mdXNp b24gYXMgDQpmb2xsb3dzOg0KICAgIDEgWW91IG1lbnRpb25lZCB0aGUgZXhjbHVzaXZpdHkgdG8g b3ZlcmxheSBjbGllbnRzLCBidXQgSSBkb24ndCB0aGluayANCnRoZSBkcmFmdC1pZXRmLXAycHNp cC1zaXAtMDEgaGFzIGV4cGxpY2l0bHkgZXhjbHVkZWQgdGhlIGNsaWVudCB1c2FnZSwgDQp3aGVy ZWFzIGl0IGRvZXNuJ3QgIG1lbnRpb24gdGhlIGNsaWVudCBzdXBwb3J0IGV4cGxpY2l0bHkuIENv dWxkIHlvdSBzaG93IA0KbWUgdGhlIGFwcGFyZW50IGNvbmZsaWN0cyB3aXRoIHRoZSBjbGllbnQg dXNhZ2UgaW4gdGhhdCBkcmFmdD9dDQoNCltHYW9dIGRyYWZ0LWlldGYtcDJwc2lwLXNpcC0wMSBz YXlzIHRoYXQgc2lwIHVzZXJzIGFyZSBwZWVycywgbm90ICpOb2RlKi4gDQpTbywgaXQgY2FuIGJl IHRyZWF0ZWQgYXMgKmV4Y2x1c2l2aXR5Ki4gRG8geW91IHRoaW5rIHNvLg0KRnVydGhlciwgY2xp ZW50cycgcm91dGluZyBhbmQgcGVlcnMnIHJvdXRpbmcgaXMgbm90IHRoZSBzYW1lIHdheS4gQW5k IEkgYW0gDQphcnJhbmdpbmcgYSBzZXBhcmF0ZSB0ZXh0IHRvIHRhbGsgYWJvdXQgdGhlIHJlYWNo YWJpbGl0eSBvZiBjbGllbnRzIHJvdXRlZCANCmJ5IE5vZGVJRC4NCg0KICAgIDIgSSBhbSBhIGxp dHRsZSBjb25mdXNlZCBhYm91dCB0aGUgZGVzY3JpcHRpb24gIiBUaGUgbWFpbiBkaWZmZXJlbmNl IA0KaXMgdGhhdCBzaXAgdXNlciByZWdpc3RlcnMgaGlzIGFkZHJlc3Mgd2hpbGUgbm90IE5vZGVJ RCwgdW5kZXIgaGlzIEFPUiJpbiANClNlY3Rpb24gMyAidGhlIG5ldyBzb2x1dGlvbiIuIEFjdHVh bGx5LCBjbGllbnQgbWF5IGhhdmUgTm9kZUlEIGluIFJFTE9BRCANCnByb3RvY29sLiBJbiB0aGUg bmV3IHNvbHV0aW9uIHdoeSBkb2VzIHRoZSBzaXAgdXNlciByZWdpc3RlciB3aXRoIGFkZHJlc3Mg DQpub3QgTm9kZUlEPyBXaGF0IGRvZXMgImFkZHJlc3MiIGhlcmUgbWVhbj8NCg0KW0dhb10gIkFk ZHJlc3MiIGlzIHRoZSBzYW1lIGFzIENvbnRyYWN0IGhlYWRlciBpbiBub3JtYWwgU0lQIHJlZ2lz dGVyIA0KbWVzc2FnZS4gV2h5IHVzaW5nICpDb250cmFjdCBhZGRyZXNzKiwgd2hpbGUgbm90IE5v ZGVJRCBpcyBhIG5pY2UgDQpxdWVzdGlvbi4NClRoZSByZWFzb24gaXMgdGhhdCBjbGllbnRzJyBy ZWFjaGFiaWxpdHkgY2FuIG5vdCBiZSBndWFyYW50ZWVkIGJ5IGFueSANCm92ZXJsYXkgd2hlbiBy b3V0aW5nIGJ5IE5vZGVJRCBmb3IgY2xpZW50cy4NCg0KICAgIDMgSW4gU2VjdGlvbiAzLjIuMSwg SSBhbSBjb25mdXNlZCBhYm91dCB0aGUgImhhbGYgc3BlbmRpbmciLiBZb3UgdXNlIA0KSUNFIG9m ZmVyL2Fuc3dlciwgdGhlIGRyYWZ0LWlldGYtcDJwc2lwLXNpcC0wMSB1c2VzIEFwcEF0dGFjaCBt ZWNoYW5pc21zLCANCmhvdyBjYW4geW91IHNheSB5b3VyIG1lY2hhbmlzbSBpcyAiaGFsZiBzcGVu ZGluZyI/DQoNCltHYW9dIElDRSBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlIGlzIGJ5cGFzcyBvZiB0 aGUgb3ZlcmxheSwgYW5kIGl0IGlzIHNlbnQgDQpkaXJlY3RseSBiZXR3ZWVuIGNhbGxlciBhbmQg Y2FsbGVlLiBCdXQgdGhlIEFwcEF0dGFjaCBoYXMgbm90IGJlIHJvdXRlZCANCnBlZXIgYnkgcGVl ci4NCg0KTXkgd2F5OiBGZXRjaDsNCmRyYWZ0LWlldGYtcDJwc2lwLXNpcC0wMSdzIHdheTogRmV0 Y2ggYW5kIEFwcEF0dGFjaC4gDQoNClNvLCBpdCBpcyBoYWxmIHNwZW5kaW5nLg0KDQogICAgSSB3 b3VsZCBhcHByZWNpYXRlIGZvciB5b3VyIHJlcGx5OikNClRhbyBNYQ0KSnVseSAyM3JkDQpCZWlq aW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucywgTW9iaWxlIGxJ ZmUgYW5kIE5ldyANCm1FZGlhIExhYg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5 IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5p Y2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdh dGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 00300802482575FC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q29tbWVudHMgaW5saW5lLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJy Pg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1 LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+VGFvIE1hICZsdDthYmNkbWF0YW9AZ21haWwuY29t Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5 LTA3LTIzIDE1OjUwPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPmdhby55YW5nMkB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Gd2Q6IFtQMlBTSVBdQSBuZXcgcHJv cG9zYWwgZm9yIFNJUA0KVXNhZ2UgZm9yIFJFTE9BRDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPjxmb250IHNpemU9Mz48YnI+DQpIaSw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgSSBoYXZl IHJlYWQgdGhlIGRyYWZ0LCB3aGljaCBwb2ludHMgb3V0IHRoZSBkcmF3YmFja3MNCm9mIGRyYWZ0 LWlldGYtcDJwc2lwLXNpcC0wMS4gQnV0IEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhbmQgY29uZnVz aW9uIGFzDQpmb2xsb3dzOjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAxIFlvdSBtZW50aW9uZWQg dGhlIGV4Y2x1c2l2aXR5IHRvIG92ZXJsYXkgY2xpZW50cywNCmJ1dCBJIGRvbid0IHRoaW5rIHRo ZSBkcmFmdC1pZXRmLXAycHNpcC1zaXAtMDEgaGFzIGV4cGxpY2l0bHkgZXhjbHVkZWQNCnRoZSBj bGllbnQgdXNhZ2UsIHdoZXJlYXMgaXQgZG9lc24ndCZuYnNwOyBtZW50aW9uIHRoZSBjbGllbnQg c3VwcG9ydCBleHBsaWNpdGx5Lg0KQ291bGQgeW91IHNob3cgbWUgdGhlIGFwcGFyZW50IGNvbmZs aWN0cyB3aXRoIHRoZSBjbGllbnQgdXNhZ2UgaW4gdGhhdA0KZHJhZnQ/XTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT5bR2FvXSBkcmFmdC1pZXRmLXAycHNpcC1zaXAt MDEgc2F5cyB0aGF0IHNpcA0KdXNlcnMgYXJlIHBlZXJzLCBub3QgKk5vZGUqLiBTbywgaXQgY2Fu IGJlIHRyZWF0ZWQgYXMgKmV4Y2x1c2l2aXR5Ki4gRG8NCnlvdSB0aGluayBzby48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+RnVydGhlciwgY2xpZW50cycgcm91dGluZyBhbmQg cGVlcnMnIHJvdXRpbmcNCmlzIG5vdCB0aGUgc2FtZSB3YXkuIEFuZCBJIGFtIGFycmFuZ2luZyBh IHNlcGFyYXRlIHRleHQgdG8gdGFsayBhYm91dCB0aGUNCnJlYWNoYWJpbGl0eSBvZiBjbGllbnRz IHJvdXRlZCBieSBOb2RlSUQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgMiBJIGFtIGEgbGl0dGxlIGNvbmZ1c2VkIGFib3V0IHRoZSBkZXNjcmlwdGlv biAmcXVvdDsNCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaGUg bWFpbiBkaWZmZXJlbmNlIGlzIHRoYXQNCnNpcCB1c2VyIHJlZ2lzdGVycyBoaXMgYWRkcmVzcyB3 aGlsZSBub3QgTm9kZUlELCB1bmRlciBoaXMgQU9SPC9mb250Pjxmb250IHNpemU9Mz4mcXVvdDtp bg0KU2VjdGlvbiAzICZxdW90O3RoZSBuZXcgc29sdXRpb24mcXVvdDsuIEFjdHVhbGx5LCBjbGll bnQgbWF5IGhhdmUgTm9kZUlEDQppbiBSRUxPQUQgcHJvdG9jb2wuIEluIHRoZSBuZXcgc29sdXRp b24gd2h5IGRvZXMgdGhlIHNpcCB1c2VyIHJlZ2lzdGVyDQp3aXRoIGFkZHJlc3Mgbm90IE5vZGVJ RD8gV2hhdCBkb2VzICZxdW90O2FkZHJlc3MmcXVvdDsgaGVyZSBtZWFuPzwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT5bR2FvXSAmcXVvdDtBZGRyZXNzJnF1b3Q7IGlz IHRoZSBzYW1lIGFzIENvbnRyYWN0DQpoZWFkZXIgaW4gbm9ybWFsIFNJUCByZWdpc3RlciBtZXNz YWdlLiBXaHkgdXNpbmcgKkNvbnRyYWN0IGFkZHJlc3MqLCB3aGlsZQ0Kbm90IE5vZGVJRCBpcyBh IG5pY2UgcXVlc3Rpb24uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPlRoZSBy ZWFzb24gaXMgdGhhdCBjbGllbnRzJyByZWFjaGFiaWxpdHkgY2FuDQpub3QgYmUgZ3VhcmFudGVl ZCBieSBhbnkgb3ZlcmxheSB3aGVuIHJvdXRpbmcgYnkgTm9kZUlEIGZvciBjbGllbnRzLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDMgSW4gU2VjdGlv biAzLjIuMSwgSSBhbSBjb25mdXNlZCBhYm91dCB0aGUgJnF1b3Q7aGFsZg0Kc3BlbmRpbmcmcXVv dDsuIFlvdSB1c2UgSUNFIG9mZmVyL2Fuc3dlciwgdGhlIGRyYWZ0LWlldGYtcDJwc2lwLXNpcC0w MQ0KdXNlcyBBcHBBdHRhY2ggbWVjaGFuaXNtcywgaG93IGNhbiB5b3Ugc2F5IHlvdXIgbWVjaGFu aXNtIGlzICZxdW90O2hhbGYNCnNwZW5kaW5nJnF1b3Q7PzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZT5bR2FvXSBJQ0Ugb2ZmZXIvYW5zd2VyIHByb2NlZHVyZSBpcyBi eXBhc3MNCm9mIHRoZSBvdmVybGF5LCBhbmQgaXQgaXMgc2VudCBkaXJlY3RseSBiZXR3ZWVuIGNh bGxlciBhbmQgY2FsbGVlLiBCdXQNCnRoZSBBcHBBdHRhY2ggaGFzIG5vdCBiZSByb3V0ZWQgcGVl ciBieSBwZWVyLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT5NeSB3 YXk6IEZldGNoOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT5kcmFmdC1pZXRm LXAycHNpcC1zaXAtMDEncyB3YXk6IEZldGNoIGFuZCBBcHBBdHRhY2guDQo8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+U28sIGl0IGlzIGhhbGYgc3BlbmRpbmcuPC9m b250Pg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgSSB3b3VsZCBh cHByZWNpYXRlIGZvciB5b3VyIHJlcGx5Oik8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSM4ODg4 ODg+PGJyPg0KVGFvIE1hPGJyPg0KSnVseSAyM3JkPGJyPg0KQmVpamluZyBVbml2ZXJzaXR5IG9m IFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMsIE1vYmlsZSBsSWZlIGFuZCBOZXcNCm1FZGlh IExhYjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJz cDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xl bHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdh bml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMm bmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7 ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2Fu ZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQm bmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3Nv bGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZu YnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDty ZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDto YXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQm bmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8 L3ByZT4= --=_alternative 00300802482575FC_=-- From abcdmatao@gmail.com Thu Jul 23 02:21:50 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638883A685F; Thu, 23 Jul 2009 02:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.841 X-Spam-Level: * X-Spam-Status: No, score=1.841 tagged_above=-999 required=5 tests=[AWL=-3.456, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvOLwdc9yNRg; Thu, 23 Jul 2009 02:21:49 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id EAF043A67B3; Thu, 23 Jul 2009 02:21:48 -0700 (PDT) Received: by gxk9 with SMTP id 9so1473333gxk.13 for ; Thu, 23 Jul 2009 02:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6SFqsESBdmlZkTcj66nIocj+M3PmqtEnJLdqcY5MCnA=; b=q0o0IRPM5k3bl3/ynhoZe0DbMTG6Y4y4Th8xuWhUu/CEPlwTNnSn+NuNuQQ2njaunP okdiTh3apyB+qd9j3yXprLzi3tN07ad73ArkA/3GE3bYbB8g4i8N00N7zKq3FCJSLXtm r0udDlZlS8CRU7sVuySZb2vbMCIfkEKRHnk1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=S4pXWy8+K4H28nYSbw4j4ZsGp6SRlx1Vn9HxGGKm1i/eGIjTHlKJiPD8svE9gzxum/ mxDqZYQx70eG8CrXYaYSPI++zmMA1QsrAEtlrHFDjob/KAzDTekrbR7uNP63DiXFjowP IKOq1FG+6PddhuXcdQxW8BW68PCUBypE1pnCs= MIME-Version: 1.0 Received: by 10.150.199.14 with SMTP id w14mr2775261ybf.259.1248340788649; Thu, 23 Jul 2009 02:19:48 -0700 (PDT) In-Reply-To: References: <99978d7d0907230049g129529ecoe2867cc3c183cbd3@mail.gmail.com> Date: Thu, 23 Jul 2009 17:19:48 +0800 Message-ID: <99978d7d0907230219k779d7ac0o7797630fc8552998@mail.gmail.com> From: Tao Ma To: gao.yang2@zte.com.cn Content-Type: multipart/alternative; boundary=000e0cd34838441f31046f5bfdf7 Cc: standardMINE@googlegroups.com, p2psip@ietf.org, p2psip-bounces@ietf.org Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBBIG5ldyBwcm9wb3NhbCBmb3IgU0lQ?= =?gb2312?b?IFVzYWdlIGZvciBSRUxPQUQ=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:21:50 -0000 --000e0cd34838441f31046f5bfdf7 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Thanks, please see inline 2009/7/23 > > Hi, > > Comments inline. > > Thanks. > > Gao > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > *Tao Ma * > =B7=A2=BC=FE=C8=CB: p2psip-bounces@ietf.org > > 2009-07-23 15:49 > =CA=D5=BC=FE=C8=CB > gaoyang2@zte.com.cn, p2psip@ietf.org > =B3=AD=CB=CD > standardMINE@googlegroups.com =D6=F7=CC=E2 > Re: [P2PSIP] A new proposal for SIP Usage for RELOAD > > > > > Hi, > I have read the draft, which points out the drawbacks of > draft-ietf-p2psip-sip-01. But I have some questions and confusion as > follows: > 1 You mentioned the exclusivity to overlay clients, but I don't think > the draft-ietf-p2psip-sip-01 has explicitly excluded the client usage, > whereas it doesn't mention the client support explicitly. Could you show= me > the apparent conflicts with the client usage in that draft? > > [Gao] draft-ietf-p2psip-sip-01 says that sip users are peers, not *Node*. > So, it can be treated as *exclusivity*. Do you think so. > Further, clients' routing and peers' routing is not the same way. And I a= m > arranging a separate text to talk about the reachability of clients route= d > by NodeID. > I come to understand that the exclusivity mainly comes from the differences between peer routing and client routing . I think the "seperate text" is badly needed to further explore the drawback of SIP usage without client routing. Here can I just conclude that the draft-ietf-p2psip-sip-01 should add client routing? > > > 2 I am a little confused about the description " The main difference i= s > that sip user registers his address while not NodeID, under his AOR"in > Section 3 "the new solution". Actually, client may have NodeID in RELOAD > protocol. In the new solution why does the sip user register with address > not NodeID? What does "address" here mean? > > > [Gao] "Address" is the same as Contract header in normal SIP register > message. Why using *Contract address*, while not NodeID is a nice questio= n. > The reason is that clients' reachability can not be guaranteed by any > overlay when routing by NodeID for clients. > It's a nice answer, thanks:) > > 3 In Section 3.2.1, I am confused about the "half spending". You use I= CE > offer/answer, the draft-ietf-p2psip-sip-01 uses AppAttach mechanisms, how > can you say your mechanism is "half spending"? > > [Gao] ICE offer/answer procedure is bypass of the overlay, and it is sent > directly between caller and callee. But the AppAttach has not be routed p= eer > by peer. > > My way: Fetch; > draft-ietf-p2psip-sip-01's way: Fetch and AppAttach. > > So, it is half spending. > In my opinion, the overlay routing is based on NodeID in RELOAD because RELOAD overlay is responsible for routing and storage. But in your way, if the contact address can be retrieved, then the routing can bypass the overlay. RELOAD overlay only stores the mapping relationship and no more routes the application messages to the destination. I think it's two kind o= f philosophy, do you think so? > > > > I would appreciate for your reply:) > Tao Ma > July 23rd > Beijing University of Posts and Telecommunications, Mobile lIfe and New > mEdia Lab_______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > --000e0cd34838441f31046f5bfdf7 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Thanks,  please see inline
2009/7/23 <gao.yang2@zte.c= om.cn>

Hi,

Comments inline.

Thanks.

Gao


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yan= g2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Tao Ma <abcdma= tao@gmail.com>
=B7=A2=BC=FE=C8=CB:  p2psip-bounces@i= etf.org

2009-07-23 15:49

=CA=D5=BC=FE=C8= =CB
gaoyang2@zte.com.cn, p2psip@ietf.org
=B3=AD=CB=CD
standardMINE@googlegroups.com
=D6=F7=CC=E2
Re: [P2PSIP] A new proposal f= or SIP Usage for RELOAD





Hi,
   I have read the draft, which points out the drawbacks of draft-ietf-p2psip-sip-01. But I have some questions and confusion as follow= s:
   1 You mentioned the exclusivity to overlay clients, but I don't think the draft-ietf-p2psip-sip-01 has explicitly excluded the cl= ient usage, whereas it doesn't  mention the client support explicitly. Could you show me the apparent conflicts with the client usage in that draft?

[Gao] draft-iet= f-p2psip-sip-01 says that sip users are peers, not *Node*. So, it can be treated as *exclusivity*. Do you think so.
Further, clients' routing and peers= ' routing is not the same way. And I am arranging a separate text to talk about the reachability of clients routed by NodeID.
I come to understand that the exclusivity mainly co= mes from the differences between peer routing and client routing . I think = the "seperate text" is badly needed to further explore the drawba= ck of SIP usage without client routing. Here can I just conclude that the d= raft-ietf-p2psip-sip-01 should add client routing?


   2 I am a little confused about the description " = The main difference is that sip user registers his address while not NodeID, under his AOR"in Section 3= "the new solution". Actually, client may have NodeID in RELOAD protocol. In the new solution why does the sip user register with address not NodeID? What does "address" here mean?


[Gao] "Add= ress" is the same as Contract header in normal SIP register message. Why using *Contract address*, while not NodeID is a nice question.
The reason is that clients' reachab= ility can not be guaranteed by any overlay when routing by NodeID for clients.
It's a nice answer, thanks:)

   3 In Section 3.2.1, I am confused about the "half spendi= ng". You use ICE offer/answer, the draft-ietf-p2psip-sip-01 uses AppAttach mecha= nisms, how can you say your mechanism is "half spending"?

[Gao] ICE offer= /answer procedure is bypass of the overlay, and it is sent directly between caller and callee. But the AppAttach has not be routed peer by peer.

My way: Fetch;
draft-ietf-p2psip-sip-01's way: Fet= ch and AppAttach.

So, it is half spending.&n= bsp;
In my opinion, the overlay routing is based on No= deID in RELOAD because RELOAD overlay is responsible for routing and storag= e. But in your way, if the contact address can be retrieved, then the routi= ng can bypass the overlay. RELOAD overlay only stores the mapping relations= hip and no more routes the application messages to the destination. I think= it's two kind of philosophy, do you think so?



   I would appreciate for your reply:)
Tao Ma
July 23rd
Beijing University of Posts and Telecommunications, Mobile lIfe and New mEdia Lab______________________________________= _________
P2PSIP mailing list
P2PSIP@ietf.org = https://www.ietf.org/mailman/listinfo/p2psip


--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

--000e0cd34838441f31046f5bfdf7-- From gao.yang2@zte.com.cn Thu Jul 23 06:10:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7FA3A6983; Thu, 23 Jul 2009 06:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.611 X-Spam-Level: X-Spam-Status: No, score=-95.611 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mymRaDsqozhS; Thu, 23 Jul 2009 06:10:56 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 6E5CF3A63EB; Thu, 23 Jul 2009 06:10:55 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91103559614510; Thu, 23 Jul 2009 17:25:42 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 85804.8402316076; Thu, 23 Jul 2009 17:31:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6N9d3Ka065033; Thu, 23 Jul 2009 17:39:04 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <99978d7d0907230219k779d7ac0o7797630fc8552998@mail.gmail.com> To: Tao Ma MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 23 Jul 2009 17:38:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-23 17:38:53, Serialize complete at 2009-07-23 17:38:53 Content-Type: multipart/alternative; boundary="=_alternative 0035037C482575FC_=" X-MAIL: mse1.zte.com.cn n6N9d3Ka065033 Cc: standardMINE@googlegroups.com, p2psip@ietf.org, p2psip-bounces@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiAgQSBuZXcgcHJvcG9z?= =?gb2312?b?YWwgZm9yIFNJUCBVc2FnZSBmb3IgUkVMT0FE?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:10:57 -0000 This is a multipart message in MIME format. --=_alternative 0035037C482575FC_= Content-Type: text/plain; charset="US-ASCII" > Hi, > I have read the draft, which points out the drawbacks of draft- > ietf-p2psip-sip-01. But I have some questions and confusion as follows: > 1 You mentioned the exclusivity to overlay clients, but I don't > think the draft-ietf-p2psip-sip-01 has explicitly excluded the > client usage, whereas it doesn't mention the client support > explicitly. Could you show me the apparent conflicts with the client > usage in that draft? > [Gao] draft-ietf-p2psip-sip-01 says that sip users are peers, not > *Node*. So, it can be treated as *exclusivity*. Do you think so. > Further, clients' routing and peers' routing is not the same way. > And I am arranging a separate text to talk about the reachability of > clients routed by NodeID. > I come to understand that the exclusivity mainly comes from the > differences between peer routing and client routing . I think the > "seperate text" is badly needed to further explore the drawback of > SIP usage without client routing. Here can I just conclude that the > draft-ietf-p2psip-sip-01 should add client routing? > [Gao] As you can see, draft-ietf-p2psip-sip-01 can modify the words from *peers* to *node*(including clients). But the problem behind it is the routing problem. And if I will arrange it as soon as possible. > > 2 I am a little confused about the description " The main > difference is that sip user registers his address while not NodeID, > under his AOR"in Section 3 "the new solution". Actually, client may > have NodeID in RELOAD protocol. In the new solution why does the sip > user register with address not NodeID? What does "address" here mean? > > [Gao] "Address" is the same as Contract header in normal SIP > register message. Why using *Contract address*, while not NodeID is > a nice question. > The reason is that clients' reachability can not be guaranteed by > any overlay when routing by NodeID for clients. > It's a nice answer, thanks:) > [Gao] It seems that you got the point here. > 3 In Section 3.2.1, I am confused about the "half spending". You > use ICE offer/answer, the draft-ietf-p2psip-sip-01 uses AppAttach > mechanisms, how can you say your mechanism is "half spending"? > [Gao] ICE offer/answer procedure is bypass of the overlay, and it is > sent directly between caller and callee. But the AppAttach has not > be routed peer by peer. > > My way: Fetch; > draft-ietf-p2psip-sip-01's way: Fetch and AppAttach. > So, it is half spending. > In my opinion, the overlay routing is based on NodeID in RELOAD > because RELOAD overlay is responsible for routing and storage. But > in your way, if the contact address can be retrieved, then the > routing can bypass the overlay. RELOAD overlay only stores the > mapping relationship and no more routes the application messages to > the destination. I think it's two kind of philosophy, do you think so? > [Gao] I have the same philosophy, but more terse. While my way has used the overlay for storage/retrieve data, it is usage of overlay. > > I would appreciate for your reply:) > Tao Ma > July 23rd > Beijing University of Posts and Telecommunications, Mobile lIfe and > New mEdia Lab_______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0035037C482575FC_= Content-Type: text/html; charset="US-ASCII"

> Hi,
>    I have read the draft, which points out the drawbacks of draft-
> ietf-p2psip-sip-01. But I have some questions and confusion as follows:
>    1 You mentioned the exclusivity to overlay clients, but I don't
> think the draft-ietf-p2psip-sip-01 has explicitly excluded the
> client usage, whereas it doesn't  mention the client support
> explicitly. Could you show me the apparent conflicts with the client
> usage in that draft?

> [Gao] draft-ietf-p2psip-sip-01 says that sip users are peers, not
> *Node*. So, it can be treated as *exclusivity*. Do you think so.
> Further, clients' routing and peers' routing is not the same way.
> And I am arranging a separate text to talk about the reachability of
> clients routed by NodeID.
> I come to understand that the exclusivity mainly comes from the
> differences between peer routing and client routing . I think the
> "seperate text" is badly needed to further explore the drawback of
> SIP usage without client routing. Here can I just conclude that the
> draft-ietf-p2psip-sip-01 should add client routing?
>

[Gao] As you can see, draft-ietf-p2psip-sip-01 can modify the words from *peers* to *node*(including clients). But the problem behind it is the routing problem.
And if I will arrange it as soon as possible.

>
>    2 I am a little confused about the description " The main
> difference is that sip user registers his address while not NodeID,
> under his AOR"in Section 3 "the new solution". Actually, client may
> have NodeID in RELOAD protocol. In the new solution why does the sip
> user register with address not NodeID? What does "address" here mean?
>

> [Gao] "Address" is the same as Contract header in normal SIP
> register message. Why using *Contract address*, while not NodeID is
> a nice question.
> The reason is that clients' reachability can not be guaranteed by
> any overlay when routing by NodeID for clients.
> It's a nice answer, thanks:)
>

[Gao] It seems that you got the point here.

>    3 In Section 3.2.1, I am confused about the "half spending". You
> use ICE offer/answer, the draft-ietf-p2psip-sip-01 uses AppAttach
> mechanisms, how can you say your mechanism is "half spending"?

> [Gao] ICE offer/answer procedure is bypass of the overlay, and it is
> sent directly between caller and callee. But the AppAttach has not
> be routed peer by peer.
>
> My way: Fetch;
> draft-ietf-p2psip-sip-01's way: Fetch and AppAttach.

> So, it is half spending.
> In my opinion, the overlay routing is based on NodeID in RELOAD
> because RELOAD overlay is responsible for routing and storage. But
> in your way, if the contact address can be retrieved, then the
> routing can bypass the overlay. RELOAD overlay only stores the
> mapping relationship and no more routes the application messages to
> the destination. I think it's two kind of philosophy, do you think so?
>

[Gao] I have the same philosophy, but more terse. While my way has used the overlay for storage/retrieve data, it is usage of overlay.



>
>    I would appreciate for your reply:)
> Tao Ma
> July 23rd
> Beijing University of Posts and Telecommunications, Mobile lIfe and
> New mEdia Lab_______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
>

> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated
> to maintain secrecy and are not permitted to disclose the contents
> of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0035037C482575FC_=-- From gao.yang2@zte.com.cn Thu Jul 23 06:10:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE313A63EB for ; Thu, 23 Jul 2009 06:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.006 X-Spam-Level: X-Spam-Status: No, score=-99.006 tagged_above=-999 required=5 tests=[AWL=2.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsLt9Vwkou21 for ; Thu, 23 Jul 2009 06:10:58 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id A8E6F3A6A04 for ; Thu, 23 Jul 2009 06:10:57 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111642075036648; Thu, 23 Jul 2009 20:21:28 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 46629.3793157739; Thu, 23 Jul 2009 20:31:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6NCdhPL064942; Thu, 23 Jul 2009 20:39:43 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: p2psip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 23 Jul 2009 20:39:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-23 20:39:29, Serialize complete at 2009-07-23 20:39:29 Content-Type: multipart/alternative; boundary="=_alternative 00458699482575FC_=" X-MAIL: mse1.zte.com.cn n6NCdhPL064942 Cc: Tao Ma Subject: Re: [P2PSIP] A new proposal for SIP Usage for RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:10:59 -0000 This is a multipart message in MIME format. --=_alternative 00458699482575FC_= Content-Type: text/plain; charset="US-ASCII" > Hi, > I have read the draft, which points out the drawbacks of draft- > ietf-p2psip-sip-01. But I have some questions and confusion as follows: > 1 You mentioned the exclusivity to overlay clients, but I don't > think the draft-ietf-p2psip-sip-01 has explicitly excluded the > client usage, whereas it doesn't mention the client support > explicitly. Could you show me the apparent conflicts with the client > usage in that draft? > [Gao] draft-ietf-p2psip-sip-01 says that sip users are peers, not > *Node*. So, it can be treated as *exclusivity*. Do you think so. > Further, clients' routing and peers' routing is not the same way. > And I am arranging a separate text to talk about the reachability of > clients routed by NodeID. > I come to understand that the exclusivity mainly comes from the > differences between peer routing and client routing . I think the > "seperate text" is badly needed to further explore the drawback of > SIP usage without client routing. Here can I just conclude that the > draft-ietf-p2psip-sip-01 should add client routing? > [Gao] As you can see, draft-ietf-p2psip-sip-01 can modify the words from *peers* to *node*(including clients). But the problem behind it is the routing problem. And if I will arrange it as soon as possible. > > 2 I am a little confused about the description " The main > difference is that sip user registers his address while not NodeID, > under his AOR"in Section 3 "the new solution". Actually, client may > have NodeID in RELOAD protocol. In the new solution why does the sip > user register with address not NodeID? What does "address" here mean? > > [Gao] "Address" is the same as Contract header in normal SIP > register message. Why using *Contract address*, while not NodeID is > a nice question. > The reason is that clients' reachability can not be guaranteed by > any overlay when routing by NodeID for clients. > It's a nice answer, thanks:) > [Gao] It seems that you got the point here. > 3 In Section 3.2.1, I am confused about the "half spending". You > use ICE offer/answer, the draft-ietf-p2psip-sip-01 uses AppAttach > mechanisms, how can you say your mechanism is "half spending"? > [Gao] ICE offer/answer procedure is bypass of the overlay, and it is > sent directly between caller and callee. But the AppAttach has not > be routed peer by peer. > > My way: Fetch; > draft-ietf-p2psip-sip-01's way: Fetch and AppAttach. > So, it is half spending. > In my opinion, the overlay routing is based on NodeID in RELOAD > because RELOAD overlay is responsible for routing and storage. But > in your way, if the contact address can be retrieved, then the > routing can bypass the overlay. RELOAD overlay only stores the > mapping relationship and no more routes the application messages to > the destination. I think it's two kind of philosophy, do you think so? > [Gao] I have the same philosophy, but more terse. While my way has used the overlay for storage/retrieve data, it is usage of overlay. =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00458699482575FC_= Content-Type: text/html; charset="US-ASCII"
> Hi,
>    I have read the draft, which points out the drawbacks of draft-
> ietf-p2psip-sip-01. But I have some questions and confusion as follows:
>    1 You mentioned the exclusivity to overlay clients, but I don't
> think the draft-ietf-p2psip-sip-01 has explicitly excluded the
> client usage, whereas it doesn't  mention the client support
> explicitly. Could you show me the apparent conflicts with the client
> usage in that draft?

> [Gao] draft-ietf-p2psip-sip-01 says that sip users are peers, not
> *Node*. So, it can be treated as *exclusivity*. Do you think so.
> Further, clients' routing and peers' routing is not the same way.
> And I am arranging a separate text to talk about the reachability of
> clients routed by NodeID.
> I come to understand that the exclusivity mainly comes from the
> differences between peer routing and client routing . I think the
> "seperate text" is badly needed to further explore the drawback of
> SIP usage without client routing. Here can I just conclude that the
> draft-ietf-p2psip-sip-01 should add client routing?
>

[Gao] As you can see, draft-ietf-p2psip-sip-01 can modify the words from *peers* to *node*(including clients). But the problem behind it is the routing problem.
And if I will arrange it as soon as possible.

>
>    2 I am a little confused about the description " The main
> difference is that sip user registers his address while not NodeID,
> under his AOR"in Section 3 "the new solution". Actually, client may
> have NodeID in RELOAD protocol. In the new solution why does the sip
> user register with address not NodeID? What does "address" here mean?
>

> [Gao] "Address" is the same as Contract header in normal SIP
> register message. Why using *Contract address*, while not NodeID is
> a nice question.
> The reason is that clients' reachability can not be guaranteed by
> any overlay when routing by NodeID for clients.
> It's a nice answer, thanks:)
>

[Gao] It seems that you got the point here.

>    3 In Section 3.2.1, I am confused about the "half spending". You
> use ICE offer/answer, the draft-ietf-p2psip-sip-01 uses AppAttach
> mechanisms, how can you say your mechanism is "half spending"?

> [Gao] ICE offer/answer procedure is bypass of the overlay, and it is
> sent directly between caller and callee. But the AppAttach has not
> be routed peer by peer.
>
> My way: Fetch;
> draft-ietf-p2psip-sip-01's way: Fetch and AppAttach.

> So, it is half spending.
> In my opinion, the overlay routing is based on NodeID in RELOAD
> because RELOAD overlay is responsible for routing and storage. But
> in your way, if the contact address can be retrieved, then the
> routing can bypass the overlay. RELOAD overlay only stores the
> mapping relationship and no more routes the application messages to
> the destination. I think it's two kind of philosophy, do you think so?
>

[Gao] I have the same philosophy, but more terse. While my way has used the overlay for storage/retrieve data, it is usage of overlay.

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00458699482575FC_=-- From davidbryan@gmail.com Fri Jul 24 12:38:14 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515A23A69C4 for ; Fri, 24 Jul 2009 12:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqp4kKD5e+Ri for ; Fri, 24 Jul 2009 12:38:13 -0700 (PDT) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 940713A69B4 for ; Fri, 24 Jul 2009 12:38:13 -0700 (PDT) Received: by ywh34 with SMTP id 34so151597ywh.29 for ; Fri, 24 Jul 2009 12:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QNXjEj3Ft7NW+DYXfQvhVH3oaa7MFaF5iESvDzCLXh0=; b=QvzKcsIA+jr+FmkmAO1r7ZqEHhprIC7dArNoc0QDaSy/C7MbQIFm6sKl9gCA2oAb+c pXY+tZlUtmENhgQbpiGtm8O0XJDy7L4QiyXtDZvrBSy0TqGT4/1BZv6Z0PvE4E46Xs67 ACGuEjq0yQoGXG0qP9mAhGMx6bLRepPA9L1/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=cyu4LeVp8PKOxrlCl2r9AXLnjgCrGeL252Ht0o6GLmlvLizhX1/9vJNq/zCqZgwWdG AHfBe7Nf58Y4jHgszoaeCo2QBnNODThY6A9dCQyta+Iy/kVLvdIVtSzepVvZyWZmMgzp 2ErWH/3HvTgmYtq+vluuPdU11xKd4tw6hjWg0= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.177.2 with SMTP id z2mr6064356ybe.138.1248464217368; Fri, 24 Jul 2009 12:36:57 -0700 (PDT) Date: Fri, 24 Jul 2009 15:36:57 -0400 X-Google-Sender-Auth: 5143a559fee4b597 Message-ID: <8b2769930907241236h356c954bif7640deca2c40e78@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Slides for P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 19:38:14 -0000 I'd like to have all the slides by 17:00 on Monday, but if anyone has things finished earlier, please send them along so I can start uploading materials to the page. Thanks, David (as chair) From fluffy@cisco.com Sat Jul 25 05:01:17 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F6F3A6A89 for ; Sat, 25 Jul 2009 05:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-9JefBP-YPp for ; Sat, 25 Jul 2009 05:01:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C31E63A69E7 for ; Sat, 25 Jul 2009 05:01:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwAAJ+QakqQ/uCKe2dsb2JhbACBUZgoAQEWJAafSYgmj3QFhAw X-IronPort-AV: E=Sophos;i="4.43,268,1246838400"; d="scan'208";a="45824153" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2009 12:01:15 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6PC1Fch013996; Sat, 25 Jul 2009 14:01:15 +0200 Received: from dhcp-50d6.meeting.ietf.org (ams3-vpn-dhcp7544.cisco.com [10.61.93.119]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6PC1FVU019270; Sat, 25 Jul 2009 12:01:15 GMT Message-Id: <2D342726-D5FE-47D2-8356-EBF17AA511EE@cisco.com> From: Cullen Jennings To: jc In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 25 Jul 2009 14:01:14 +0200 References: X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=655; t=1248523275; x=1249387275; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Two=20Credential-Server=20El ements=20Described |Sender:=20; bh=lt16bdakKcRkkS7mKqZQT6HLk0NHAWsg92S3EYtlai4=; b=GzE1j1IPWbdtX6VjOCJHyudmCbT+Hc4282KDz/gAf/rAz5DapAGNIdfOJt 76wNUtTuM4TBhnXRYlG155mi0C0o3dSpr7hGOp5XO/2w/PVPHCs9Og6IxCCX SfeQQs3WwS; Authentication-Results: ams-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Two Credential-Server Elements Described X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 12:01:17 -0000 Thanks for catching this. The first one is correct. I have removed 2nd from the XML. On Jul 19, 2009, at 21:13 , jc wrote: > There are two credential-server elements, which one is correct? > > credential-server This element contains the URL at which the > credential server can be reached in a "url" element. This URL > MUST be of type "https:". More than one credential-server > element > may be present. > > credential-server Base URL for credential server. > > jc > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@idssoftware.com Sun Jul 26 09:49:50 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6323A6A98 for ; Sun, 26 Jul 2009 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVK06Bhttu31 for ; Sun, 26 Jul 2009 09:49:49 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 451583A6A04 for ; Sun, 26 Jul 2009 09:49:49 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MV6v0-0001RP-6Z for p2psip@ietf.org; Sun, 26 Jul 2009 12:49:50 -0400 Message-ID: <4A6C8A3C.6030507@idssoftware.com> Date: Sun, 26 Jul 2009 09:54:20 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: p2psip@ietf.org References: <20090714000001.D94FA28C458@core3.amsl.com> In-Reply-To: <20090714000001.D94FA28C458@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da9406f78bceeb8ba19e8930f13e7948bb953350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Subject: Re: [P2PSIP] I-D Action:draft-ietf-p2psip-base-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 16:49:50 -0000 Hi, Nice to see progress. Here are things I want to point out and suggest: 1) Section 5.5.1.1, the definition IceCandidate.rel_addr_port does not conform with the current mmusic-ice-19 section 15.1, which has the following text: " and : convey transport addresses related to the candidate, useful for diagnostics and other purposes. and MUST be present for server reflexive, peer reflexive and relayed candidates." Therefore, the definition of IceCandidate should be: struct { ... select (type){ case host: ; /* Nothing */ case srflx: case prflx: case relay: IpAddressPort rel_addr_port; } ... } IceCandidate; rel_addr_port corresponds to the related address and port of ICE, which MUST present for type "srflx", "prflx" and "relay". 2) In Section 13.6, IANA message codes for AppAttachReq and AppAttachReq are not added. I suggest fill these two values (app_attach_req=5, app_attach_ans=6) in the holes left by the abandoned tunnel_req and tunnel_ans. 3) In Section 6.4.1.2, if the store request has multiple kinds, the current answer structure will send replica node IDs multiple times. For efficiency, I suggest moving the replica node IDs to the outer layer as: struct { KindId kind; uint64 generation_counter; } StoreKindResponse; struct { StoreKindResponse kind_responses<0..2^16-1>; NodeId replicas<0..2^16-1>; } StoreAns; 4) It seems that mmusic-ice-tcp-07 has been abandoned. The key members of this draft should address the lack of ice-tcp standard in the next draft, meeting or on the mailing list. Assuming this group is no longer interested in mmusic-ice-tcp-07, something like this should be added to section 5.5.1.5 to make things clear: For peers that support TCP/TLS, the ICE TCP host candidates are the addresses and port number of each network interface it listens to. They may also be the address and port number accessible to other peers via methods described in draft-lowekamp-mmusic-ice-tcp-framework. When forming ICE check candidate pairs, a local TCP candidate is paired with a remote TCP candidate of matching address type (IPv4 or IPv6). In addition, for peers in "active" or "act-pass" role, a new port number MUST be allocate for the local candidate in the pair. This is often done automatically by the operating system when the program calls the connect() function of the socket library to creates a TCP connection to the remote candidate address. That is it so far. Thanks --Michael Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. > > > Title : REsource LOcation And Discovery (RELOAD) Base Protocol > Author(s) : C. Jennings, et al. > Filename : draft-ietf-p2psip-base-03.txt > Pages : 146 > Date : 2009-07-13 > > In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC > 3979 respectively. They refer only to those RFCs and not any > documents that update or supersede them. > > This document defines REsource LOcation And Discovery (RELOAD), a > peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P > signaling protocol provides its clients with an abstract storage and > messaging service between a set of cooperating peers that form the > overlay network. RELOAD is designed to support a P2P Session > Initiation Protocol (P2PSIP) network, but can be utilized by other > applications with similar requirements by defining new usages that > specify the kinds of data that must be stored for a particular > application. RELOAD defines a security model based on a certificate > enrollment service that provides unique identities. NAT traversal is > a fundamental service of the protocol. RELOAD also allows access > from "client" nodes that do not need to route traffic or store data > for others. > > Legal > > This documents and the information contained therein are provided on > an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS > FOR A PARTICULAR PURPOSE. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From ekr@networkresonance.com Mon Jul 27 09:44:24 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C9A28C219 for ; Mon, 27 Jul 2009 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYNV78FITbHu for ; Mon, 27 Jul 2009 09:44:23 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id E6E7928C0D7 for ; Mon, 27 Jul 2009 09:44:22 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7DB4750822 for ; Mon, 27 Jul 2009 09:47:58 -0700 (PDT) Date: Mon, 27 Jul 2009 09:47:58 -0700 From: Eric Rescorla To: p2psip@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090727164758.7DB4750822@romeo.rtfm.com> Subject: [P2PSIP] Review of draft-vidya-p2psip-eclients-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:44:24 -0000 $Id: draft-vidya-p2psip-eclients-00-rev.txt,v 1.1 2009/07/27 14:42:14 ekr Exp $ After reading this draft, I don't see what it brings to the party. RELOAD currently supports clients in two ways: 1. Clients can attach to the peer responsible for their node ID (I'll call this RP). At this point they're universally reachable, but through the RP. 2. Clients can attach to arbitrary other peers in the overlay. They can immediately send request through those peers, and responses will pass back through those peers via symmetric routing. If you advertise a route stack, you can arrange that requests go to you directly. Otherwise, requests have to go through the RP. Note that these approaches can be used in tandem. I.e., you connect to the RP for requests *to* you and to other (topologically closer on the real network) closer to you for requests from you. As I understand the value proposition of this draft, it is intended to serve in cases where either the RP is unreachable from the client or merely unattractive. The way it does this is by having the client connect to a Direct Attachment Point (DP) which then connects to the RP (called OAP here). As before, requests to the client go through the OAP and then the DAP, but the client can originate requests through the DAP. This is presented as an optimization, and it is over method (1), but it's not really an optimization over methods (1) and (2) used together. The one respect in which it is an improvement, that I can see, is that it covers cases in which the client cannot connect directly to the RP or in which the client is mobile and would have to repeatedly reconnect to the RP, whereas the DAP can be used as a stable point. However, it seems to me that this same effect could be achieved simply by having the DAP actually be a TURN server. The client could then connect to the TURN server and through it to the RP. You get the same message paths, but there's no additional protocol mechanisms required to tell anyone that this is a client--everything just works. It also has the additional advantage that because TURN servers have public IPs, you know you won't have to send OAP-DAP messages through the overlay. -Ekr From bbl@lowekamp.net Mon Jul 27 09:54:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B131D28C238 for ; Mon, 27 Jul 2009 09:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsRZdAwRIoyd for ; Mon, 27 Jul 2009 09:54:15 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 24C6428C320 for ; Mon, 27 Jul 2009 09:54:04 -0700 (PDT) Received: by bwz21 with SMTP id 21so354269bwz.37 for ; Mon, 27 Jul 2009 09:54:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.69 with SMTP id b5mr2708166fas.107.1248713643475; Mon, 27 Jul 2009 09:54:03 -0700 (PDT) In-Reply-To: <20090727164758.7DB4750822@romeo.rtfm.com> References: <20090727164758.7DB4750822@romeo.rtfm.com> Date: Mon, 27 Jul 2009 18:54:03 +0200 Message-ID: From: Bruce Lowekamp To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Review of draft-vidya-p2psip-eclients-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:54:15 -0000 On Mon, Jul 27, 2009 at 6:47 PM, Eric Rescorla wrote: > However, it seems to me that this same effect could be achieved > simply by having the DAP actually be a TURN server. The client > could then connect to the TURN server and through it to the > RP. You get the same message paths, but there's no additional > protocol mechanisms required to tell anyone that this is > a client--everything just works. It also has the additional advantage > that because TURN servers have public IPs, you know you won't > have to send OAP-DAP messages through the overlay. > This doesn't work when peers can be behind NATs. There's no way to ensure that the responsible peer has a public IP and can be a TURN server. I think the concept of allowing a client to be contacted by routing a message to the client's Node-ID regardless of whether it is directly attached or not is a very useful one. I think a couple minor changes might be needed to the base draft to allow an extension or usage to specify how to do/manage this behavior, but I believe it's definitely worth the effort. Bruce From ekr@rtfm.com Mon Jul 27 10:09:24 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48DDF28C33F for ; Mon, 27 Jul 2009 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5axuO5Qsthq for ; Mon, 27 Jul 2009 10:09:23 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 7459728C342 for ; Mon, 27 Jul 2009 10:09:23 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so800499rvb.49 for ; Mon, 27 Jul 2009 10:09:04 -0700 (PDT) Received: by 10.141.49.21 with SMTP id b21mr4157350rvk.196.1248714544714; Mon, 27 Jul 2009 10:09:04 -0700 (PDT) Received: from ?10.153.220.166? ([166.205.130.222]) by mx.google.com with ESMTPS id g22sm24271219rvb.3.2009.07.27.10.09.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 10:09:03 -0700 (PDT) References: <20090727164758.7DB4750822@romeo.rtfm.com> Message-Id: From: Eric Rescorla To: Bruce Lowekamp In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Date: Mon, 27 Jul 2009 10:08:55 -0700 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Review of draft-vidya-p2psip-eclients-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:09:24 -0000 On Jul 27, 2009, at 9:54 AM, Bruce Lowekamp wrote: > On Mon, Jul 27, 2009 at 6:47 PM, Eric Rescorla > wrote: >> However, it seems to me that this same effect could be achieved >> simply by having the DAP actually be a TURN server. The client >> could then connect to the TURN server and through it to the >> RP. You get the same message paths, but there's no additional >> protocol mechanisms required to tell anyone that this is >> a client--everything just works. It also has the additional advantage >> that because TURN servers have public IPs, you know you won't >> have to send OAP-DAP messages through the overlay. >> > > This doesn't work when peers can be behind NATs. There's no way to > ensure that the responsible peer has a public IP and can be a TURN > server. That's not what I said. The dap, which has no special node relationship with the client, is the turn server. > I think the concept of allowing a client to be contacted by routing a > message to the client's Node-ID regardless of whether it is directly > attached or not is a very useful one. I think a couple minor changes > might be needed to the base draft to allow an extension or usage to > specify how to do/manage this behavior, but I believe it's definitely > worth the effort. > 1. I'm unconvinced. The arguments presented so far seem weak 2. The changes in this draft don't seem minor to me Ekr > Bruce > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Mon Jul 27 10:17:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A044B28C1C1 for ; Mon, 27 Jul 2009 10:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5Xj-L-B9s5A for ; Mon, 27 Jul 2009 10:17:07 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 56AB63A682F for ; Mon, 27 Jul 2009 10:17:07 -0700 (PDT) Received: by bwz21 with SMTP id 21so367998bwz.37 for ; Mon, 27 Jul 2009 10:17:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.103.194 with SMTP id l2mr2762212fao.55.1248715021984; Mon, 27 Jul 2009 10:17:01 -0700 (PDT) In-Reply-To: References: <20090727164758.7DB4750822@romeo.rtfm.com> Date: Mon, 27 Jul 2009 19:17:01 +0200 Message-ID: From: Bruce Lowekamp To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Review of draft-vidya-p2psip-eclients-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:17:08 -0000 On Mon, Jul 27, 2009 at 7:08 PM, Eric Rescorla wrote: > > > On Jul 27, 2009, at 9:54 AM, Bruce Lowekamp wrote: > >> On Mon, Jul 27, 2009 at 6:47 PM, Eric Rescorla >> wrote: >>> >>> However, it seems to me that this same effect could be achieved >>> simply by having the DAP actually be a TURN server. The client >>> could then connect to the TURN server and through it to the >>> RP. You get the same message paths, but there's no additional >>> protocol mechanisms required to tell anyone that this is >>> a client--everything just works. It also has the additional advantage >>> that because TURN servers have public IPs, you know you won't >>> have to send OAP-DAP messages through the overlay. >>> >> >> This doesn't work when peers can be behind NATs. =C2=A0There's no way to >> ensure that the responsible peer has a public IP and can be a TURN >> server. > > That's not what I said. The dap, which has no special node relationship w= ith > the client, is the turn server. The DAP was being selected for other criteria, such as having an existing bluetooth connection to the client. That doesn't make it a good candidate for a turn server, either. > >> I think the concept of allowing a client to be contacted by routing a >> message to the client's Node-ID regardless of whether it is directly >> attached or not is a very useful one. =C2=A0I think a couple minor chang= es >> might be needed to the base draft to allow an extension or usage to >> specify how to do/manage this behavior, but I believe it's definitely >> worth the effort. >> > 1. I'm unconvinced. The arguments presented so far seem weak > 2. The changes in this draft don't seem minor to me I think the changes needed to the base draft to support extensions/usages for client routing are minor. Managing it properly is more complicated, which I think is a good topic for this draft. Bruce From gao.yang2@zte.com.cn Mon Jul 27 14:03:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841CA3A6CE9 for ; Mon, 27 Jul 2009 14:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.956 X-Spam-Level: X-Spam-Status: No, score=-98.956 tagged_above=-999 required=5 tests=[AWL=2.882, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVuSN-VKMoZe for ; Mon, 27 Jul 2009 14:03:06 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 453C53A6D28 for ; Mon, 27 Jul 2009 14:03:06 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111642075036648; Tue, 28 Jul 2009 04:44:41 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 12290.2075036648; Tue, 28 Jul 2009 04:55:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6RL0Dp8058131 for ; Tue, 28 Jul 2009 05:00:13 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: p2psip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 28 Jul 2009 05:00:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-28 05:00:14, Serialize complete at 2009-07-28 05:00:14 Content-Type: multipart/alternative; boundary="=_alternative 00735F4148257600_=" X-MAIL: mse2.zte.com.cn n6RL0Dp8058131 Subject: [P2PSIP] New Version Notification for draft-gaoyang-p2psip-new-sip-usage-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 21:03:07 -0000 This is a multipart message in MIME format. --=_alternative 00735F4148257600_= Content-Type: text/plain; charset="US-ASCII" A new version of I-D, draft-gaoyang-p2psip-new-sip-usage-00.txt has been successfuly submitted by Gao yang and posted to the IETF repository. Filename: draft-gaoyang-p2psip-new-sip-usage Revision: 00 Title: A New SIP Usage for RELOAD Creation_date: 2009-07-27 WG ID: Independent Submission Number_of_pages: 9 URL: http://www.ietf.org/id/draft-gaoyang-p2psip-new-sip-usage-00.txt Abstract: This document points out the main drawbacks of the solution in "draft-ietf-p2psip-sip-01". And solve such problems by introducing a new way. The IETF Secretariat. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00735F4148257600_= Content-Type: text/html; charset="US-ASCII"

A new version of I-D, draft-gaoyang-p2psip-new-sip-usage-00.txt has been successfuly submitted by Gao yang and posted to the IETF repository.

Filename:                  draft-gaoyang-p2psip-new-sip-usage
Revision:                  00
Title:                                   A New SIP Usage for RELOAD
Creation_date:                  2009-07-27
WG ID:                                   Independent Submission
Number_of_pages: 9

URL: http://www.ietf.org/id/draft-gaoyang-p2psip-new-sip-usage-00.txt

Abstract:
This document points out the main drawbacks of the solution in
"draft-ietf-p2psip-sip-01".  And solve such problems by introducing a
new way.
                                                                                 


The IETF Secretariat.




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00735F4148257600_=-- From bbl@lowekamp.net Tue Jul 28 00:58:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26DE3A67BD for ; Tue, 28 Jul 2009 00:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBvtzqv1htNe for ; Tue, 28 Jul 2009 00:58:01 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 088CD3A691A for ; Tue, 28 Jul 2009 00:58:00 -0700 (PDT) Received: by bwz21 with SMTP id 21so719925bwz.37 for ; Tue, 28 Jul 2009 00:57:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.127.8 with SMTP id e8mr3016216fas.80.1248767875031; Tue, 28 Jul 2009 00:57:55 -0700 (PDT) Date: Tue, 28 Jul 2009 09:57:55 +0200 Message-ID: From: Bruce Lowekamp To: p2psip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] changes to *Attach* methods in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 07:58:02 -0000 With the -03 draft, we now have four Attach variants Attach AttachLite AppAttach AppAttachLite We also have to face the additional problem that ICE-TCP is not making progress, so having normative dependencies on it at this point seems problematic. I would like to propose that we address these two problems by merging the Lite and non-Lite variants into the base methods, so we have only Attach and AppAttach. The request structures will be modified to contain either ICE parameters or the current Lite information. The meaning of the Lite structure will remain the same---only use this in a situation where the node is certain it is publicly reachable, otherwise connectivity will fail. If we write the section so that we implicitly support future extensions to ICE, we should hopefully require no changes should ICE-TCP eventually be completed. Otherwise, if an alternative mechanism for negotiating TCP is developed, a minor extension should be possible to incorporate it. Comments or suggestions? I'd like to have rough consensus on this change before looking into the details of implementing it. Bruce From bbl@lowekamp.net Tue Jul 28 01:14:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE6C3A6CEB for ; Tue, 28 Jul 2009 01:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61uB7jd4ppid for ; Tue, 28 Jul 2009 01:14:35 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 7C5C13A6ABC for ; Tue, 28 Jul 2009 01:14:35 -0700 (PDT) Received: by bwz21 with SMTP id 21so728617bwz.37 for ; Tue, 28 Jul 2009 01:14:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.110.200 with SMTP id o8mr3075388fap.56.1248768873115; Tue, 28 Jul 2009 01:14:33 -0700 (PDT) Date: Tue, 28 Jul 2009 10:14:33 +0200 Message-ID: From: Bruce Lowekamp To: p2psip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] adding option header to all methods X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:14:36 -0000 Part of a recent thread about Client support discussed the option of adding additional semantics to an existing method vs adding a new method. We currently have extension points for some structures, but we don't have a general way for an extension to add new semantics or options to an existing method. One possible solution is to add an Option header to the existing methods, in the same spirit of ForwardingOption in the forwarding header. A TLV structure with an option for whether it is mandatory/optional to understand would allow significant extensibility without defining new methods for every new extension. Bruce From bbl@lowekamp.net Tue Jul 28 01:26:26 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6923A6CE0 for ; Tue, 28 Jul 2009 01:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTHLK7QBZnkV for ; Tue, 28 Jul 2009 01:26:25 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 75F923A6C79 for ; Tue, 28 Jul 2009 01:26:25 -0700 (PDT) Received: by bwz21 with SMTP id 21so734471bwz.37 for ; Tue, 28 Jul 2009 01:26:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.119.198 with SMTP id a6mr3115395far.42.1248769583609; Tue, 28 Jul 2009 01:26:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Jul 2009 10:26:23 +0200 Message-ID: From: Bruce Lowekamp To: p2psip Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [P2PSIP] clients in reload and Update X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:26:26 -0000 On Fri, Jul 17, 2009 at 4:46 AM, Bruce Lowekamp wrote: > > 1) rely on the clients to periodically Ping or Route_Query to ensure > they are connected to the correct peer. =C2=A0Unfortunately, this leaves = an > obvious gap before the topology change is noticed. =C2=A0Unlike > sip-outbound, we don't have redundant connections to compensate for > temporary loss of reachability. > > 2) define a new method for this purpose that is generic, so > independent of overlay algorithm > > 3) retain the current use of Update, and specify that a client > receiving an Update that it cannot process (because it does not speak > the overlay algorithm) SHOULD perform a Route_Query to confirm it is > still connected to the proper peer. > > > My personal preference is option 3, because I dislike the performance > tradeoffs of option 1, and I think option 3 has all of the > functionality option 2 would have anyway. > > > On a slightly separate note, I'm a bit concerned about the ability to > establish a client's ability to establish a reliable connection with > its responsible peer. =C2=A0In Chord, for example, greater reliability > would be achieved by establishing a connection with the responsible > peer and n successors. =C2=A0If a peer receives a message routed to a nod= e > for which it is responsible but has no connection, it could then > forward that message to its n successors to attempt to deliver it. > Currently the peer would drop the message silently. > After thinking about it some more, I'm wondering if a better option might be to define a new method that allows a client to query for the replica set for a Resource-ID and for the peer to inform its connected non-overlay-topology nodes when the replica set for a Resource-ID changes. This would address both of these problems at the same time without requiring clients to speak the overlay algorithm. Bruce From bbl@lowekamp.net Tue Jul 28 01:55:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD3C3A6892 for ; Tue, 28 Jul 2009 01:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVSTsvP30DuK for ; Tue, 28 Jul 2009 01:55:06 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 99D3A3A6D82 for ; Tue, 28 Jul 2009 01:55:05 -0700 (PDT) Received: by bwz21 with SMTP id 21so750054bwz.37 for ; Tue, 28 Jul 2009 01:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.115.193 with SMTP id j1mr3105335faq.98.1248771302898; Tue, 28 Jul 2009 01:55:02 -0700 (PDT) Date: Tue, 28 Jul 2009 10:55:02 +0200 Message-ID: From: Bruce Lowekamp To: p2psip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] comments on draft-matuszewski-p2psip-security-requirements-05 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:55:06 -0000 I thought this revision of the document was a significant improvement and thank the authors for spending so much time reorganizing and rewriting pieces of it. I liked the general discussion of issues. When it got into the RELOAD-specific part I was less certain how to apply it. It might be helpful if the draft uses RELOAD to refer to the specific protocol and P2PSIP or even another term to discuss general p2p communications system issues to avoid confusion. This draft appears to have the wrong IPR declaration at the beginning. Since it incorporates material that was contributed prior to 11/2008, it can't use this declaration. I still find the term "overlay base" confusing. Again, depending on whether parts of the discussion are intended to be general about p2p telecom or specific to RELOAD and work in the p2psip working group, some of the discussion and terms need to be updated. For example, there is no separate protocol for peer vs client communication (even though there is discussion of whether additional methods are needed for client operation, I don't believe anyone is arguing for separate protocols at this point). Bruce From gao.yang2@zte.com.cn Tue Jul 28 03:59:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B8C3A6A70; Tue, 28 Jul 2009 03:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.006 X-Spam-Level: X-Spam-Status: No, score=-94.006 tagged_above=-999 required=5 tests=[AWL=-3.028, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHb4i8Zn0Jwg; Tue, 28 Jul 2009 03:59:08 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 73A993A6D00; Tue, 28 Jul 2009 03:59:06 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111643559614510; Tue, 28 Jul 2009 18:40:41 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 46629.4700318305; Tue, 28 Jul 2009 18:50:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6SAT4RU016285; Tue, 28 Jul 2009 18:29:05 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Bruce Lowekamp MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 28 Jul 2009 18:28:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-28 18:28:53, Serialize complete at 2009-07-28 18:28:53 Content-Type: multipart/alternative; boundary="=_alternative 0039911E48257601_=" X-MAIL: mse2.zte.com.cn n6SAT4RU016285 Cc: p2psip , p2psip-bounces@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBjbGllbnRzIGluIHJlbG9hZCBhbmQg?= =?gb2312?b?VXBkYXRl?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 10:59:09 -0000 This is a multipart message in MIME format. --=_alternative 0039911E48257601_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBU ZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2Fv LnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN Cg0KDQpCcnVjZSBMb3dla2FtcCA8YmJsQGxvd2VrYW1wLm5ldD4gDQq3orz+yMs6ICBwMnBzaXAt Ym91bmNlc0BpZXRmLm9yZw0KMjAwOS0wNy0yOCAxNjoyNg0KDQrK1bz+yMsNCnAycHNpcCA8cDJw c2lwQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpSZTogW1AyUFNJUF0gY2xpZW50cyBpbiByZWxv YWQgYW5kIFVwZGF0ZQ0KDQoNCg0KDQoNCg0KT24gRnJpLCBKdWwgMTcsIDIwMDkgYXQgNDo0NiBB TSwgQnJ1Y2UgTG93ZWthbXA8YmJsQGxvd2VrYW1wLm5ldD4gd3JvdGU6DQo+DQo+IDEpIHJlbHkg b24gdGhlIGNsaWVudHMgdG8gcGVyaW9kaWNhbGx5IFBpbmcgb3IgUm91dGVfUXVlcnkgdG8gZW5z dXJlDQo+IHRoZXkgYXJlIGNvbm5lY3RlZCB0byB0aGUgY29ycmVjdCBwZWVyLiAgVW5mb3J0dW5h dGVseSwgdGhpcyBsZWF2ZXMgYW4NCj4gb2J2aW91cyBnYXAgYmVmb3JlIHRoZSB0b3BvbG9neSBj aGFuZ2UgaXMgbm90aWNlZC4gIFVubGlrZQ0KPiBzaXAtb3V0Ym91bmQsIHdlIGRvbid0IGhhdmUg cmVkdW5kYW50IGNvbm5lY3Rpb25zIHRvIGNvbXBlbnNhdGUgZm9yDQo+IHRlbXBvcmFyeSBsb3Nz IG9mIHJlYWNoYWJpbGl0eS4NCj4NCj4gMikgZGVmaW5lIGEgbmV3IG1ldGhvZCBmb3IgdGhpcyBw dXJwb3NlIHRoYXQgaXMgZ2VuZXJpYywgc28NCj4gaW5kZXBlbmRlbnQgb2Ygb3ZlcmxheSBhbGdv cml0aG0NCj4NCj4gMykgcmV0YWluIHRoZSBjdXJyZW50IHVzZSBvZiBVcGRhdGUsIGFuZCBzcGVj aWZ5IHRoYXQgYSBjbGllbnQNCj4gcmVjZWl2aW5nIGFuIFVwZGF0ZSB0aGF0IGl0IGNhbm5vdCBw cm9jZXNzIChiZWNhdXNlIGl0IGRvZXMgbm90IHNwZWFrDQo+IHRoZSBvdmVybGF5IGFsZ29yaXRo bSkgU0hPVUxEIHBlcmZvcm0gYSBSb3V0ZV9RdWVyeSB0byBjb25maXJtIGl0IGlzDQo+IHN0aWxs IGNvbm5lY3RlZCB0byB0aGUgcHJvcGVyIHBlZXIuDQo+DQo+DQo+IE15IHBlcnNvbmFsIHByZWZl cmVuY2UgaXMgb3B0aW9uIDMsIGJlY2F1c2UgSSBkaXNsaWtlIHRoZSBwZXJmb3JtYW5jZQ0KPiB0 cmFkZW9mZnMgb2Ygb3B0aW9uIDEsIGFuZCBJIHRoaW5rIG9wdGlvbiAzIGhhcyBhbGwgb2YgdGhl DQo+IGZ1bmN0aW9uYWxpdHkgb3B0aW9uIDIgd291bGQgaGF2ZSBhbnl3YXkuDQo+DQo+DQo+IE9u IGEgc2xpZ2h0bHkgc2VwYXJhdGUgbm90ZSwgSSdtIGEgYml0IGNvbmNlcm5lZCBhYm91dCB0aGUg YWJpbGl0eSB0bw0KPiBlc3RhYmxpc2ggYSBjbGllbnQncyBhYmlsaXR5IHRvIGVzdGFibGlzaCBh IHJlbGlhYmxlIGNvbm5lY3Rpb24gd2l0aA0KPiBpdHMgcmVzcG9uc2libGUgcGVlci4gIEluIENo b3JkLCBmb3IgZXhhbXBsZSwgZ3JlYXRlciByZWxpYWJpbGl0eQ0KPiB3b3VsZCBiZSBhY2hpZXZl ZCBieSBlc3RhYmxpc2hpbmcgYSBjb25uZWN0aW9uIHdpdGggdGhlIHJlc3BvbnNpYmxlDQo+IHBl ZXIgYW5kIG4gc3VjY2Vzc29ycy4gIElmIGEgcGVlciByZWNlaXZlcyBhIG1lc3NhZ2Ugcm91dGVk IHRvIGEgbm9kZQ0KPiBmb3Igd2hpY2ggaXQgaXMgcmVzcG9uc2libGUgYnV0IGhhcyBubyBjb25u ZWN0aW9uLCBpdCBjb3VsZCB0aGVuDQo+IGZvcndhcmQgdGhhdCBtZXNzYWdlIHRvIGl0cyBuIHN1 Y2Nlc3NvcnMgdG8gYXR0ZW1wdCB0byBkZWxpdmVyIGl0Lg0KPiBDdXJyZW50bHkgdGhlIHBlZXIg d291bGQgZHJvcCB0aGUgbWVzc2FnZSBzaWxlbnRseS4NCj4NCg0KQWZ0ZXIgdGhpbmtpbmcgYWJv dXQgaXQgc29tZSBtb3JlLCBJJ20gd29uZGVyaW5nIGlmIGEgYmV0dGVyIG9wdGlvbg0KbWlnaHQg YmUgdG8gZGVmaW5lIGEgbmV3IG1ldGhvZCB0aGF0IGFsbG93cyBhIGNsaWVudCB0byBxdWVyeSBm b3IgdGhlDQpyZXBsaWNhIHNldCBmb3IgYSBSZXNvdXJjZS1JRCBhbmQgZm9yIHRoZSBwZWVyIHRv IGluZm9ybSBpdHMgY29ubmVjdGVkDQpub24tb3ZlcmxheS10b3BvbG9neSBub2RlcyB3aGVuIHRo ZSByZXBsaWNhIHNldCBmb3IgYSBSZXNvdXJjZS1JRA0KY2hhbmdlcy4gIFRoaXMgd291bGQgYWRk cmVzcyBib3RoIG9mIHRoZXNlIHByb2JsZW1zIGF0IHRoZSBzYW1lIHRpbWUNCndpdGhvdXQgcmVx dWlyaW5nIGNsaWVudHMgdG8gc3BlYWsgdGhlIG92ZXJsYXkgYWxnb3JpdGhtLg0KDQpCcnVjZQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClAyUFNJUCBt YWlsaW5nIGxpc3QNClAyUFNJUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wMnBzaXANCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9w ZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlv biBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0 byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUg Y29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5k IGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hv bSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZp ZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFs IHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBT cGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0039911E48257601_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVs ICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4Nzcy MTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5CcnVjZSBMb3dla2FtcCAmbHQ7YmJsQGxvd2VrYW1wLm5ldCZn dDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7I yzogJm5ic3A7cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNy0yOCAxNjoyNjwvZm9udD4NCjx0ZCB3aWR0aD03MyU+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5wMnBzaXAgJmx0O3AycHNpcEBpZXRm Lm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbUDJQU0lQXSBjbGllbnRzIGluIHJlbG9hZCBhbmQgVXBkYXRlPC9mb250 PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3Rh YmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5PbiBG cmksIEp1bCAxNywgMjAwOSBhdCA0OjQ2IEFNLCBCcnVjZSBMb3dla2FtcCZsdDtiYmxAbG93ZWth bXAubmV0Jmd0Ow0Kd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgMSkgcmVseSBvbiB0aGUgY2xp ZW50cyB0byBwZXJpb2RpY2FsbHkgUGluZyBvciBSb3V0ZV9RdWVyeSB0byBlbnN1cmU8YnI+DQom Z3Q7IHRoZXkgYXJlIGNvbm5lY3RlZCB0byB0aGUgY29ycmVjdCBwZWVyLiAmbmJzcDtVbmZvcnR1 bmF0ZWx5LCB0aGlzDQpsZWF2ZXMgYW48YnI+DQomZ3Q7IG9idmlvdXMgZ2FwIGJlZm9yZSB0aGUg dG9wb2xvZ3kgY2hhbmdlIGlzIG5vdGljZWQuICZuYnNwO1VubGlrZTxicj4NCiZndDsgc2lwLW91 dGJvdW5kLCB3ZSBkb24ndCBoYXZlIHJlZHVuZGFudCBjb25uZWN0aW9ucyB0byBjb21wZW5zYXRl IGZvcjxicj4NCiZndDsgdGVtcG9yYXJ5IGxvc3Mgb2YgcmVhY2hhYmlsaXR5Ljxicj4NCiZndDs8 YnI+DQomZ3Q7IDIpIGRlZmluZSBhIG5ldyBtZXRob2QgZm9yIHRoaXMgcHVycG9zZSB0aGF0IGlz IGdlbmVyaWMsIHNvPGJyPg0KJmd0OyBpbmRlcGVuZGVudCBvZiBvdmVybGF5IGFsZ29yaXRobTxi cj4NCiZndDs8YnI+DQomZ3Q7IDMpIHJldGFpbiB0aGUgY3VycmVudCB1c2Ugb2YgVXBkYXRlLCBh bmQgc3BlY2lmeSB0aGF0IGEgY2xpZW50PGJyPg0KJmd0OyByZWNlaXZpbmcgYW4gVXBkYXRlIHRo YXQgaXQgY2Fubm90IHByb2Nlc3MgKGJlY2F1c2UgaXQgZG9lcyBub3Qgc3BlYWs8YnI+DQomZ3Q7 IHRoZSBvdmVybGF5IGFsZ29yaXRobSkgU0hPVUxEIHBlcmZvcm0gYSBSb3V0ZV9RdWVyeSB0byBj b25maXJtIGl0DQppczxicj4NCiZndDsgc3RpbGwgY29ubmVjdGVkIHRvIHRoZSBwcm9wZXIgcGVl ci48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgTXkgcGVyc29uYWwgcHJlZmVyZW5jZSBp cyBvcHRpb24gMywgYmVjYXVzZSBJIGRpc2xpa2UgdGhlIHBlcmZvcm1hbmNlPGJyPg0KJmd0OyB0 cmFkZW9mZnMgb2Ygb3B0aW9uIDEsIGFuZCBJIHRoaW5rIG9wdGlvbiAzIGhhcyBhbGwgb2YgdGhl PGJyPg0KJmd0OyBmdW5jdGlvbmFsaXR5IG9wdGlvbiAyIHdvdWxkIGhhdmUgYW55d2F5Ljxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBhIHNsaWdodGx5IHNlcGFyYXRlIG5vdGUsIEkn bSBhIGJpdCBjb25jZXJuZWQgYWJvdXQgdGhlIGFiaWxpdHkNCnRvPGJyPg0KJmd0OyBlc3RhYmxp c2ggYSBjbGllbnQncyBhYmlsaXR5IHRvIGVzdGFibGlzaCBhIHJlbGlhYmxlIGNvbm5lY3Rpb24g d2l0aDxicj4NCiZndDsgaXRzIHJlc3BvbnNpYmxlIHBlZXIuICZuYnNwO0luIENob3JkLCBmb3Ig ZXhhbXBsZSwgZ3JlYXRlciByZWxpYWJpbGl0eTxicj4NCiZndDsgd291bGQgYmUgYWNoaWV2ZWQg YnkgZXN0YWJsaXNoaW5nIGEgY29ubmVjdGlvbiB3aXRoIHRoZSByZXNwb25zaWJsZTxicj4NCiZn dDsgcGVlciBhbmQgbiBzdWNjZXNzb3JzLiAmbmJzcDtJZiBhIHBlZXIgcmVjZWl2ZXMgYSBtZXNz YWdlIHJvdXRlZCB0bw0KYSBub2RlPGJyPg0KJmd0OyBmb3Igd2hpY2ggaXQgaXMgcmVzcG9uc2li bGUgYnV0IGhhcyBubyBjb25uZWN0aW9uLCBpdCBjb3VsZCB0aGVuPGJyPg0KJmd0OyBmb3J3YXJk IHRoYXQgbWVzc2FnZSB0byBpdHMgbiBzdWNjZXNzb3JzIHRvIGF0dGVtcHQgdG8gZGVsaXZlciBp dC48YnI+DQomZ3Q7IEN1cnJlbnRseSB0aGUgcGVlciB3b3VsZCBkcm9wIHRoZSBtZXNzYWdlIHNp bGVudGx5Ljxicj4NCiZndDs8YnI+DQo8YnI+DQpBZnRlciB0aGlua2luZyBhYm91dCBpdCBzb21l IG1vcmUsIEknbSB3b25kZXJpbmcgaWYgYSBiZXR0ZXIgb3B0aW9uPGJyPg0KbWlnaHQgYmUgdG8g ZGVmaW5lIGEgbmV3IG1ldGhvZCB0aGF0IGFsbG93cyBhIGNsaWVudCB0byBxdWVyeSBmb3IgdGhl PGJyPg0KcmVwbGljYSBzZXQgZm9yIGEgUmVzb3VyY2UtSUQgYW5kIGZvciB0aGUgcGVlciB0byBp bmZvcm0gaXRzIGNvbm5lY3RlZDxicj4NCm5vbi1vdmVybGF5LXRvcG9sb2d5IG5vZGVzIHdoZW4g dGhlIHJlcGxpY2Egc2V0IGZvciBhIFJlc291cmNlLUlEPGJyPg0KY2hhbmdlcy4gJm5ic3A7VGhp cyB3b3VsZCBhZGRyZXNzIGJvdGggb2YgdGhlc2UgcHJvYmxlbXMgYXQgdGhlIHNhbWUgdGltZTxi cj4NCndpdGhvdXQgcmVxdWlyaW5nIGNsaWVudHMgdG8gc3BlYWsgdGhlIG92ZXJsYXkgYWxnb3Jp dGhtLjxicj4NCjxicj4NCkJydWNlPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpQMlBTSVAgbWFpbGluZyBsaXN0PGJyPg0KUDJQU0lQQGll dGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8 YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJz cDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xl bHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdh bml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMm bmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7 ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2Fu ZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQm bmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3Nv bGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZu YnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDty ZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDto YXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQm bmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8 L3ByZT4= --=_alternative 0039911E48257601_=-- From hishigh@gmail.com Tue Jul 28 04:39:08 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E453A6DA7 for ; Tue, 28 Jul 2009 04:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8ZzWZXr207R for ; Tue, 28 Jul 2009 04:39:06 -0700 (PDT) Received: from mail-pz0-f173.google.com (mail-pz0-f173.google.com [209.85.222.173]) by core3.amsl.com (Postfix) with ESMTP id 21E753A6A25 for ; Tue, 28 Jul 2009 04:39:06 -0700 (PDT) Received: by pzk3 with SMTP id 3so641240pzk.29 for ; Tue, 28 Jul 2009 04:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ClcE2J/8XGL53PtD1gLyLeiIuP7RnZdUOotIgSow7yU=; b=g4AzPmcXa61D/fR3IkbaMtFrRWSonU+39TEeBaRBL1UJ4R3KWehjnt5WQ0oSCINLEp XdiYsCzETbl2s6/XbUDYJz6bdcGEHLiZuDERv71j8pqVB+KrT6DWkz6ubqAzGu2UUfDB 6xEZ+e8QTZ8Dn2uCmkSa9cqv5LRG2P1M6lGA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YrPwotOUYHONfJFwDxkkTyT2S6qxt1CeabRt0QFu62UQNvQ8N7oiGo6rER74kJ3hkM cqYd9fJjRN1n0uJZWrRqXWRuBMFm7O8FIrb/0AxUv1OQcTamBEIGMrkc/f8ALRmT+8CR q+pqypNNOxb6der1QJimDr6QL40wEwZA1t/Ck= MIME-Version: 1.0 Received: by 10.142.155.7 with SMTP id c7mr903981wfe.41.1248781145921; Tue, 28 Jul 2009 04:39:05 -0700 (PDT) Date: Tue, 28 Jul 2009 19:39:05 +0800 Message-ID: <8bd755250907280439o10c3c864qd90f81c0a66e1513@mail.gmail.com> From: yunfei zhang To: P2PSIP Mailing List Content-Type: multipart/alternative; boundary=000e0cd2de149ad7fe046fc2848c Subject: [P2PSIP] PPSP (P2P streaming protocol) final bar bof agenda X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 11:39:08 -0000 --000e0cd2de149ad7fe046fc2848c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,all, The PPSP (P2P streaming protocol) final bar bof agenda is updated as follows. Welcome to attend with us.Any suggestions and contributions are appreciated. PPSP Final Bar BoF-- IETF 75, Stockholm 2000-2200 Thursday,July 30,Room 300. Mailing list=A3=BAppsp@ietf.org http://www.ietf.org/mailman/listinfo/ppsp Chair: Yunfei Zhang( zhangyunfei@chinamobile.com) Gonzalo Camarillo *( *gonzalo.camarillo@ericsson.com) (One more may involve) AD: Lars Eggert( lars.eggert@nokia.com) Agenda 1. Introduction and Agenda bashing (Chair,10') 2. Problem Statement (Yunfei Zhang, 40') draft-zhang-ppsp-problem-statement-04 3.Discussion =A3=A8All,20'=A3=A9 4. Other Drafts (the time length is variable depending on the above discussion time) ---- Protocol Analysis of PPlive, PPStream and UUSee by Interent Measurement (Yunfei Zhang,5') draft-zhang-ppsp-protocol-comparison-measurement-02 ----Chunk Discovery for P2P Streaming (Ning Zong, 10=A1=AF) draft-zong-ppsp-chunk-discovery-00 5. Discussion (All, 20') 6. Decisions and HUMs (All, 10') 7. Conclusions and Next Steps (Chairs/ADs, 5') BR Yunfei --000e0cd2de149ad7fe046fc2848c Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi,all,<= /font>

   The PPSP (P2P streaming protocol) final = bar bof agenda is updated as follows. Welcome to attend with us.Any suggest= ions and contributions are appreciated.

  

  PPSP Fi= nal Bar BoF-- IETF 75, Stockholm

  2000-2200 Thursday,July 30,Room 300.

  Mailing list=A3=BAppsp@ietf.org http://www.ietf.org/mailman/listinfo/pps= p

  Chair: Yunfe= i Zhang( zhangyunfei@chinamo= bile.com)

   &= nbsp;        Gonzalo Camarillo ( gonzalo.camarillo@ericsson.com)

   &= nbsp;        (One more may involve)

   AD: La= rs Eggert( lars.eggert@nokia.com) 

 

 

 

Agenda

1. Introduction and= Agenda bashing   <= span style=3D"mso-spacerun: yes">       =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =           (Chair,1= 0')  <= /p>

          =             &nb= sp;            =             &nb= sp;            =             &nb= sp;    

2. Problem Statemen= t      &nbs= p;                  = ;     &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;       (Yunfei Zhang, 40')=

   draft-zhang-ppsp-problem-statement-= 04 

 

3.Discussion        =             &nb= sp;     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  =A3=A8All,20'= =A3=A9

 

4. Other Drafts (th= e time length is variable depending on the above discussion time)

  ---- Pr= otocol Analysis of PPlive, PPStream and UUSee by Interent Measurement        = ;            &n= bsp;      (Yunfei Zhang,5')

         draft-zhang-ppsp-protocol-compar= ison-measurement-02&n= bsp;

  ----Chunk Discovery for P2P Streaming =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;(Ning Zong, 10’)

        draft-z= ong-ppsp-chunk-discovery-00 

 

5.

 Discussion         =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;           (All, = 20')

 

6. Decisions and HUMs     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           (All, 10'= ;)

 

7. Conclusions and Next Steps   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   (Chairs/ADs, 5')   

 

 

          =             &nb= sp;            =      BR

          =             &nb= sp;            =        Yunfei

 
--000e0cd2de149ad7fe046fc2848c-- From bbl@lowekamp.net Tue Jul 28 04:46:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505BF3A6EAD for ; Tue, 28 Jul 2009 04:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft9gQ27NvDhr for ; Tue, 28 Jul 2009 04:46:02 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 3422D3A6EAE for ; Tue, 28 Jul 2009 04:46:02 -0700 (PDT) Received: by bwz21 with SMTP id 21so845471bwz.37 for ; Tue, 28 Jul 2009 04:45:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.109.198 with SMTP id k6mr3316913fap.46.1248781558937; Tue, 28 Jul 2009 04:45:58 -0700 (PDT) Date: Tue, 28 Jul 2009 13:45:58 +0200 Message-ID: From: Bruce Lowekamp To: p2psip@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] comments on draft-ietf-p2psip-diagnostics-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 11:46:03 -0000 I liked most of the changes that were made since the previous revision. A few comments on this draft: It can't use the IPR declaration that it's using. There is material in here from other drafts (the old diagnostics text) that was submitted prior to 11/2008 and has not been officially reassigned under the new terms. The draft refers to Inspect as Ping. Since there's a Ping method in RELOAD, this is very confusing, especially since I think we've discussed adding a NodeFetch method to support such applications periodically. There currently isn't an option for processing by on-path peers as discussed by 5.4.2. That could be added as a ForwardingOption. Personally I don't like it and would oppose requiring it, but I think that's the right way to proceed with such an idea. This draft could really benefit from a few detailed examples of how to use some of the specific elements. Right now there are ways to query for a lot of different information, but it's not completely clear which elements should be selected for inclusion. For example, you can detect some misrouting with some of these methods, but doing so is quite hard. I think we may want to raise the question of error_info/sub-codes to a separate thread on the list for a general discussion. Given that we have 16 bits for error codes in RELOAD, I'm not sure sub-codes are really needed. Path_Track is sort of a merger of RouteQuery and Fetch. The motivation for defining it as a separate method is, I think, that if you're trying to diagnose route instability, it's helpful to be able to ask those two questions simultaneously before the route changes again. The draft should be a bit clearer on motivating that. From ekr@networkresonance.com Tue Jul 28 06:39:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF793A6FA1 for ; Tue, 28 Jul 2009 06:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiNZOpFMWg1v for ; Tue, 28 Jul 2009 06:39:51 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 1D9943A6F94 for ; Tue, 28 Jul 2009 06:39:51 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2764B50822; Tue, 28 Jul 2009 06:43:27 -0700 (PDT) Date: Tue, 28 Jul 2009 06:43:26 -0700 From: Eric Rescorla To: Bruce Lowekamp In-Reply-To: References: <20090727164758.7DB4750822@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20090728134327.2764B50822@romeo.rtfm.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Review of draft-vidya-p2psip-eclients-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 13:39:52 -0000 At Mon, 27 Jul 2009 19:17:01 +0200, Bruce Lowekamp wrote: >=20 > On Mon, Jul 27, 2009 at 7:08 PM, Eric Rescorla wrote: > > > > > > On Jul 27, 2009, at 9:54 AM, Bruce Lowekamp wrote: > > > >> On Mon, Jul 27, 2009 at 6:47 PM, Eric Rescorla > >> wrote: > >>> > >>> However, it seems to me that this same effect could be achieved > >>> simply by having the DAP actually be a TURN server. The client > >>> could then connect to the TURN server and through it to the > >>> RP. You get the same message paths, but there's no additional > >>> protocol mechanisms required to tell anyone that this is > >>> a client--everything just works. It also has the additional advantage > >>> that because TURN servers have public IPs, you know you won't > >>> have to send OAP-DAP messages through the overlay. > >>> > >> > >> This doesn't work when peers can be behind NATs. =A0There's no way to > >> ensure that the responsible peer has a public IP and can be a TURN > >> server. > > > > That's not what I said. The dap, which has no special node relationship= with > > the client, is the turn server. >=20 > The DAP was being selected for other criteria, such as having an > existing bluetooth connection to the client. That doesn't make it a > good candidate for a turn server, either. Well, you don't actually need to be a full TURN server, just one good enough to do ordinary connections.=20 But that said, I don't find this Bluethooth special case very compelling. If you're going over Bluetooth, this is much more like having a split client and much less like having a client with an IP connection to some DAP. -Ekr From wang.jun17@zte.com.cn Tue Jul 28 08:51:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F07A3A6EB9; Tue, 28 Jul 2009 08:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.816 X-Spam-Level: X-Spam-Status: No, score=-92.816 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiYU9KT-tag0; Tue, 28 Jul 2009 08:51:30 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 8CF3E3A6DE0; Tue, 28 Jul 2009 08:51:29 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111643559614510; Tue, 28 Jul 2009 23:32:58 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 46629.6795251208; Tue, 28 Jul 2009 23:43:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6SFNiRT018967; Tue, 28 Jul 2009 23:24:13 +0800 (CST) (envelope-from wang.jun17@zte.com.cn) In-Reply-To: <20090728134327.2764B50822@romeo.rtfm.com> To: Eric Rescorla MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wang.jun17@zte.com.cn Date: Tue, 28 Jul 2009 17:23:50 +0200 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-28 23:23:56, Serialize complete at 2009-07-28 23:23:56 Content-Type: multipart/alternative; boundary="=_alternative 005493BCC1257601_=" X-MAIL: mse2.zte.com.cn n6SFNiRT018967 Cc: "p2psip@ietf.org" , p2psip-bounces@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBSZXZpZXcgb2YgZHJhZnQtdmlkeWEt?= =?gb2312?b?cDJwc2lwLWVjbGllbnRzLTAw?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:51:31 -0000 This is a multipart message in MIME format. --=_alternative 005493BCC1257601_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDA5LTA3LTI4IDE1OjQzOjI2Og0KDQo+IEF0 IE1vbiwgMjcgSnVsIDIwMDkgMTk6MTc6MDEgKzAyMDAsDQo+IEJydWNlIExvd2VrYW1wIHdyb3Rl Og0KPiA+IA0KPiA+IE9uIE1vbiwgSnVsIDI3LCAyMDA5IGF0IDc6MDggUE0sIEVyaWMgUmVzY29y bGE8ZWtyQHJ0Zm0uY29tPiB3cm90ZToNCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gSnVsIDI3LCAy MDA5LCBhdCA5OjU0IEFNLCBCcnVjZSBMb3dla2FtcCA8YmJsQGxvd2VrYW1wLm5ldD4gDQp3cm90 ZToNCj4gPiA+DQo+ID4gPj4gT24gTW9uLCBKdWwgMjcsIDIwMDkgYXQgNjo0NyBQTSwgRXJpYyAN ClJlc2NvcmxhPGVrckBuZXR3b3JrcmVzb25hbmNlLmNvbT4NCj4gPiA+PiB3cm90ZToNCj4gPiA+ Pj4NCj4gPiA+Pj4gSG93ZXZlciwgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIHNhbWUgZWZmZWN0 IGNvdWxkIGJlIGFjaGlldmVkDQo+ID4gPj4+IHNpbXBseSBieSBoYXZpbmcgdGhlIERBUCBhY3R1 YWxseSBiZSBhIFRVUk4gc2VydmVyLiBUaGUgY2xpZW50DQo+ID4gPj4+IGNvdWxkIHRoZW4gY29u bmVjdCB0byB0aGUgVFVSTiBzZXJ2ZXIgYW5kIHRocm91Z2ggaXQgdG8gdGhlDQo+ID4gPj4+IFJQ LiBZb3UgZ2V0IHRoZSBzYW1lIG1lc3NhZ2UgcGF0aHMsIGJ1dCB0aGVyZSdzIG5vIGFkZGl0aW9u YWwNCj4gPiA+Pj4gcHJvdG9jb2wgbWVjaGFuaXNtcyByZXF1aXJlZCB0byB0ZWxsIGFueW9uZSB0 aGF0IHRoaXMgaXMNCj4gPiA+Pj4gYSBjbGllbnQtLWV2ZXJ5dGhpbmcganVzdCB3b3Jrcy4gSXQg YWxzbyBoYXMgdGhlIGFkZGl0aW9uYWwgDQphZHZhbnRhZ2UNCj4gPiA+Pj4gdGhhdCBiZWNhdXNl IFRVUk4gc2VydmVycyBoYXZlIHB1YmxpYyBJUHMsIHlvdSBrbm93IHlvdSB3b24ndA0KPiA+ID4+ PiBoYXZlIHRvIHNlbmQgT0FQLURBUCBtZXNzYWdlcyB0aHJvdWdoIHRoZSBvdmVybGF5Lg0KPiA+ ID4+Pg0KPiA+ID4+DQo+ID4gPj4gVGhpcyBkb2Vzbid0IHdvcmsgd2hlbiBwZWVycyBjYW4gYmUg YmVoaW5kIE5BVHMuICBUaGVyZSdzIG5vIHdheSB0bw0KPiA+ID4+IGVuc3VyZSB0aGF0IHRoZSBy ZXNwb25zaWJsZSBwZWVyIGhhcyBhIHB1YmxpYyBJUCBhbmQgY2FuIGJlIGEgVFVSTg0KPiA+ID4+ IHNlcnZlci4NCj4gPiA+DQo+ID4gPiBUaGF0J3Mgbm90IHdoYXQgSSBzYWlkLiBUaGUgZGFwLCB3 aGljaCBoYXMgbm8gc3BlY2lhbCBub2RlIA0KPiByZWxhdGlvbnNoaXAgd2l0aA0KPiA+ID4gdGhl IGNsaWVudCwgaXMgdGhlIHR1cm4gc2VydmVyLg0KPiA+IA0KPiA+IFRoZSBEQVAgd2FzIGJlaW5n IHNlbGVjdGVkIGZvciBvdGhlciBjcml0ZXJpYSwgc3VjaCBhcyBoYXZpbmcgYW4NCj4gPiBleGlz dGluZyBibHVldG9vdGggY29ubmVjdGlvbiB0byB0aGUgY2xpZW50LiAgVGhhdCBkb2Vzbid0IG1h a2UgaXQgYQ0KPiA+IGdvb2QgY2FuZGlkYXRlIGZvciBhIHR1cm4gc2VydmVyLCBlaXRoZXIuDQo+ IA0KPiBXZWxsLCB5b3UgZG9uJ3QgYWN0dWFsbHkgbmVlZCB0byBiZSBhIGZ1bGwgVFVSTiBzZXJ2 ZXIsIGp1c3Qgb25lDQo+IGdvb2QgZW5vdWdoIHRvIGRvIG9yZGluYXJ5IGNvbm5lY3Rpb25zLiAN Cj4gDQo+IEJ1dCB0aGF0IHNhaWQsIEkgZG9uJ3QgZmluZCB0aGlzIEJsdWV0aG9vdGggc3BlY2lh bCBjYXNlIHZlcnkNCj4gY29tcGVsbGluZy4gSWYgeW91J3JlIGdvaW5nIG92ZXIgQmx1ZXRvb3Ro LCB0aGlzIGlzIG11Y2ggbW9yZSBsaWtlDQo+IGhhdmluZyBhIHNwbGl0IGNsaWVudCBhbmQgbXVj aCBsZXNzIGxpa2UgaGF2aW5nIGEgY2xpZW50IHdpdGggYW4NCj4gSVAgY29ubmVjdGlvbiB0byBz b21lIERBUC4NCj4gDQoNCkkgdGhpbmsgdGhlcmUgYXJlIHR3byBzY2VuYXJpb3Mgd2hlcmUgdGhl IGNsaWVudCBzaG91bGQgbm90IGFsd2F5cyBjb25uZWN0IA0KdG8gdGhlIE9BUDoNCjEuIEZvciB0 cmFmZmljIGxvY2FsaXphdGlvbiBwdXJwb3NlLCB0aGUgY2xpZW50IGF0dGFjaGVzIHRvIGEgDQpn ZW9ncmFwaGljYWxseSBuZWFyZXIgcGVlci4NCjIuIFRvIGtlZXAgdGhlIHNlcnZpY2UgbW9yZSBy ZWxpYWJsZSwgdGhlIGNsaWVudCBjb25uZWN0cyB0byB0d28gb3IgbW9yZSANCnBlZXJzLg0KDQoN ClJ1c3NlbGwgV2FuZw0KDQo+IC1Fa3INCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPiBQMlBTSVBAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCj4gDQoN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVj aXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11 bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBz eXN0ZW0uDQo= --=_alternative 005493BCC1257601_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5wMnBzaXAtYm91bmNlc0BpZXRmLm9yZyDlhpnkuo4gMjAw OS0wNy0yOCAxNTo0MzoyNjo8YnI+DQo8YnI+DQomZ3Q7IEF0IE1vbiwgMjcgSnVsIDIwMDkgMTk6 MTc6MDEgKzAyMDAsPGJyPg0KJmd0OyBCcnVjZSBMb3dla2FtcCB3cm90ZTo8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIE1vbiwgSnVsIDI3LCAyMDA5IGF0IDc6MDggUE0sIEVyaWMg UmVzY29ybGEmbHQ7ZWtyQHJ0Zm0uY29tJmd0Ow0Kd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIEp1bCAyNywgMjAwOSwg YXQgOTo1NCBBTSwgQnJ1Y2UgTG93ZWthbXAgJmx0O2JibEBsb3dla2FtcC5uZXQmZ3Q7DQp3cm90 ZTo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBPbiBNb24sIEp1 bCAyNywgMjAwOSBhdCA2OjQ3IFBNLCBFcmljIFJlc2NvcmxhJmx0O2VrckBuZXR3b3JrcmVzb25h bmNlLmNvbSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgSG93ZXZlciwgaXQgc2Vl bXMgdG8gbWUgdGhhdCB0aGlzIHNhbWUgZWZmZWN0IGNvdWxkDQpiZSBhY2hpZXZlZDxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDsgc2ltcGx5IGJ5IGhhdmluZyB0aGUgREFQIGFjdHVhbGx5IGJl IGEgVFVSTiBzZXJ2ZXIuDQpUaGUgY2xpZW50PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBj b3VsZCB0aGVuIGNvbm5lY3QgdG8gdGhlIFRVUk4gc2VydmVyIGFuZCB0aHJvdWdoDQppdCB0byB0 aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IFJQLiBZb3UgZ2V0IHRoZSBzYW1lIG1lc3Nh Z2UgcGF0aHMsIGJ1dCB0aGVyZSdzDQpubyBhZGRpdGlvbmFsPGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7Jmd0OyBwcm90b2NvbCBtZWNoYW5pc21zIHJlcXVpcmVkIHRvIHRlbGwgYW55b25lIHRoYXQN CnRoaXMgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGEgY2xpZW50LS1ldmVyeXRoaW5n IGp1c3Qgd29ya3MuIEl0IGFsc28gaGFzIHRoZQ0KYWRkaXRpb25hbCBhZHZhbnRhZ2U8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHRoYXQgYmVjYXVzZSBUVVJOIHNlcnZlcnMgaGF2ZSBwdWJs aWMgSVBzLCB5b3Uga25vdw0KeW91IHdvbid0PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBo YXZlIHRvIHNlbmQgT0FQLURBUCBtZXNzYWdlcyB0aHJvdWdoIHRoZSBvdmVybGF5Ljxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsgVGhpcyBkb2Vzbid0IHdvcmsgd2hlbiBwZWVycyBjYW4gYmUgYmVoaW5kIE5B VHMuICZuYnNwO1RoZXJlJ3MNCm5vIHdheSB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBlbnN1 cmUgdGhhdCB0aGUgcmVzcG9uc2libGUgcGVlciBoYXMgYSBwdWJsaWMgSVAgYW5kDQpjYW4gYmUg YSBUVVJOPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IHNlcnZlci48YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYXQncyBub3Qgd2hhdCBJIHNhaWQuIFRoZSBkYXAsIHdo aWNoIGhhcyBubyBzcGVjaWFsIG5vZGUNCjxicj4NCiZndDsgcmVsYXRpb25zaGlwIHdpdGg8YnI+ DQomZ3Q7ICZndDsgJmd0OyB0aGUgY2xpZW50LCBpcyB0aGUgdHVybiBzZXJ2ZXIuPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGUgREFQIHdhcyBiZWluZyBzZWxlY3RlZCBmb3Igb3Ro ZXIgY3JpdGVyaWEsIHN1Y2ggYXMgaGF2aW5nDQphbjxicj4NCiZndDsgJmd0OyBleGlzdGluZyBi bHVldG9vdGggY29ubmVjdGlvbiB0byB0aGUgY2xpZW50LiAmbmJzcDtUaGF0IGRvZXNuJ3QNCm1h a2UgaXQgYTxicj4NCiZndDsgJmd0OyBnb29kIGNhbmRpZGF0ZSBmb3IgYSB0dXJuIHNlcnZlciwg ZWl0aGVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXZWxsLCB5b3UgZG9uJ3QgYWN0dWFsbHkgbmVl ZCB0byBiZSBhIGZ1bGwgVFVSTiBzZXJ2ZXIsIGp1c3Qgb25lPGJyPg0KJmd0OyBnb29kIGVub3Vn aCB0byBkbyBvcmRpbmFyeSBjb25uZWN0aW9ucy4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJ1dCB0 aGF0IHNhaWQsIEkgZG9uJ3QgZmluZCB0aGlzIEJsdWV0aG9vdGggc3BlY2lhbCBjYXNlIHZlcnk8 YnI+DQomZ3Q7IGNvbXBlbGxpbmcuIElmIHlvdSdyZSBnb2luZyBvdmVyIEJsdWV0b290aCwgdGhp cyBpcyBtdWNoIG1vcmUgbGlrZTxicj4NCiZndDsgaGF2aW5nIGEgc3BsaXQgY2xpZW50IGFuZCBt dWNoIGxlc3MgbGlrZSBoYXZpbmcgYSBjbGllbnQgd2l0aCBhbjxicj4NCiZndDsgSVAgY29ubmVj dGlvbiB0byBzb21lIERBUC48YnI+DQomZ3Q7IDwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+SSB0aGluayB0aGVyZSBhcmUgdHdvIHNjZW5hcmlvcyB3aGVyZSB0aGUgY2xp ZW50IHNob3VsZA0Kbm90IGFsd2F5cyBjb25uZWN0IHRvIHRoZSBPQVA6PC90dD48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yPjx0dD4xLiBGb3IgdHJhZmZpYyBsb2NhbGl6YXRpb24gcHVycG9zZSwg dGhlIGNsaWVudCBhdHRhY2hlcw0KdG8gYSBnZW9ncmFwaGljYWxseSBuZWFyZXIgcGVlci48L3R0 PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PjIuIFRvIGtlZXAgdGhlIHNlcnZpY2UgbW9y ZSByZWxpYWJsZSwgdGhlIGNsaWVudCBjb25uZWN0cw0KdG8gdHdvIG9yIG1vcmUgcGVlcnMuPC90 dD48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5SdXNzZWxsIFdhbmc8 L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiZndDsgLUVrcjxicj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7IFAyUFNJUCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IFAyUFNJUEBpZXRmLm9yZzxicj4NCiZn dDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8YnI+DQomZ3Q7 IDxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJz cDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2Nv bnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZu YnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXph dGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNw O2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNw O2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5i c3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNj bG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVu aWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5i c3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNw O2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5 Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7 YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2Vp dmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZu YnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNw O21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZu YnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNw O1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJl Pg== --=_alternative 005493BCC1257601_=-- From davidbryan@gmail.com Wed Jul 29 02:00:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED833A6F1F for ; Wed, 29 Jul 2009 02:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKI6hVc-GYhs for ; Wed, 29 Jul 2009 02:00:52 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id F2E473A699F for ; Wed, 29 Jul 2009 02:00:51 -0700 (PDT) Received: by gxk9 with SMTP id 9so1185061gxk.13 for ; Wed, 29 Jul 2009 02:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=VrdQWbvtoD+V1AM5IcTlrkj9MUC3sEK3UgJ22IFbjXk=; b=G8t9oS9ZSIYm22UO2nLL+fptvq9MLTJXZh5iQBQJIPT9Co/sLM+0KjiqQJiPbOLv5R 63F3ENMVaCrsSkOLl4PloycI8mhZCWKXh24CoXvVCi2T+H5BSBmWQt8/OORhISs1xRrL D0vTp1JzjELjNNd/UZZ6EhwXRZgDBQREmc2Rk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EUkTTyAt6LPaQ1HNZkDvPd0QrnyVYJ5ppMg57YFD/Hyx6MViKqw2ps588bYJ06NVwu +mS+0JqkGExBicIPlpcDMDx66+lcHhTor8IQYLOKwpyJcgE452szQOdh94NZKWcmnsTu cvF4K/wUqRrK8Omyyy7VvIMW2wPX7STS7AFeQ= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.151.157.16 with SMTP id j16mr1065092ybo.174.1248858051853; Wed, 29 Jul 2009 02:00:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2009 11:00:51 +0200 X-Google-Sender-Auth: 325b5086da825bab Message-ID: <8b2769930907290200k283e7ef4sf1f9b553b65e6424@mail.gmail.com> From: "David A. Bryan" To: Bruce Lowekamp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] adding option header to all methods X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:00:52 -0000 I'd certainly support this. I think in the meeting someone already said it, but will better to have this and not need it than need it and not have it. David (as individual) On Tue, Jul 28, 2009 at 10:14 AM, Bruce Lowekamp wrote: > Part of a recent thread about Client support discussed the option of > adding additional semantics to an existing method vs adding a new > method. We currently have extension points for some structures, but > we don't have a general way for an extension to add new semantics or > options to an existing method. > > One possible solution is to add an Option header to the existing > methods, in the same spirit of ForwardingOption in the forwarding > header. A TLV structure with an option for whether it is > mandatory/optional to understand would allow significant extensibility > without defining new methods for every new extension. > > Bruce > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From erkkih@ee.oulu.fi Wed Jul 29 04:40:39 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93273A6FBD for ; Wed, 29 Jul 2009 04:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIfr2oeMtRFo for ; Wed, 29 Jul 2009 04:40:39 -0700 (PDT) Received: from oulu.fi (ousrvr.oulu.fi [130.231.240.1]) by core3.amsl.com (Postfix) with ESMTP id CCAEA3A67B4 for ; Wed, 29 Jul 2009 04:40:38 -0700 (PDT) Received: from paju.oulu.fi (paju.oulu.fi [130.231.240.20]) by oulu.fi (8.13.7/8.13.7) with ESMTP id n6TBecvU022642 for ; Wed, 29 Jul 2009 14:40:38 +0300 (EEST) Received: from [127.0.0.1] (paju.oulu.fi [130.231.240.20]) by paju.oulu.fi (8.13.7/8.13.7) with ESMTP id n6TBea1o002396; Wed, 29 Jul 2009 14:40:38 +0300 (EEST) Message-ID: <4A703538.5050702@ee.oulu.fi> Date: Wed, 29 Jul 2009 13:40:40 +0200 From: Erkki Harjula User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "'P2PSIP WG'" References: <048201c9ff81$31bace80$0f0ca40a@china.huawei.com> In-Reply-To: <048201c9ff81$31bace80$0f0ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Battery status information to diagnostics draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:40:39 -0000 Hi, as requested in P2PSIP session yesterday, I restate here on the list my comment regarding battery status information. I think including battery status information would be useful to include in the draft. It would be useful e.g. in peer/client mode decision or load balancing, where battery status information could be used to relieve the load of those nodes running on batteries (just two examples among many others!). As everybody knows, more and more devices nowadays, especially in P2PSIP scenarios, are battery operated. The status info could be the remaining battery percentage, or simply a binary value telling whether the node is running on its batteries or not. -Erkki From julian@orchidseed.org Wed Jul 29 12:14:05 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE96F3A6F9F for ; Wed, 29 Jul 2009 12:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d2Ks1xSbfBZ for ; Wed, 29 Jul 2009 12:14:05 -0700 (PDT) Received: from mail-px0-f185.google.com (mail-px0-f185.google.com [209.85.216.185]) by core3.amsl.com (Postfix) with ESMTP id 424C53A6E37 for ; Wed, 29 Jul 2009 12:14:04 -0700 (PDT) Received: by pxi15 with SMTP id 15so22425pxi.31 for ; Wed, 29 Jul 2009 12:14:03 -0700 (PDT) Received: by 10.114.171.16 with SMTP id t16mr206917wae.111.1248894843888; Wed, 29 Jul 2009 12:14:03 -0700 (PDT) Received: from ?10.0.1.8? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id j34sm1937665waf.26.2009.07.29.12.14.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 12:14:03 -0700 (PDT) Message-Id: From: jc To: Erkki Harjula In-Reply-To: <4A703538.5050702@ee.oulu.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 12:14:00 -0700 References: <048201c9ff81$31bace80$0f0ca40a@china.huawei.com> <4A703538.5050702@ee.oulu.fi> X-Mailer: Apple Mail (2.935.3) Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Battery status information to diagnostics draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 19:14:05 -0000 IMHO, this should be a binary value representative of the % of energy a device may have available at any given time. This covers solar, wind, etc and not simply "battery" as far as terminology is concerned. Who's to say a solar based geo-sync satellite might not be running as a p2psip node one day with battery backup on board? ;-) jc On Jul 29, 2009, at 4:40 AM, Erkki Harjula wrote: > Hi, > > as requested in P2PSIP session yesterday, I restate here on the list > my comment regarding battery status information. > > I think including battery status information would be useful to > include in the draft. It would be useful e.g. in peer/client mode > decision or load balancing, where battery status information could > be used to relieve the load of those nodes running on batteries > (just two examples among many others!). As everybody knows, more and > more devices nowadays, especially in P2PSIP scenarios, are battery > operated. > > The status info could be the remaining battery percentage, or simply > a binary value telling whether the node is running on its batteries > or not. > > -Erkki > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From saumitra@qualcomm.com Thu Jul 30 02:19:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B075828C1C9 for ; Thu, 30 Jul 2009 02:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al5M+Cab0l6Y for ; Thu, 30 Jul 2009 02:19:06 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E0D9128C284 for ; Thu, 30 Jul 2009 02:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1248945521; x=1280481521; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20jc=20,=20Erkki=20Harjula=20|CC:=20"'P2PSIP=20WG'"=20 |Date:=20Thu,=2030=20Jul=202009=2002:18:28=20-0700 |Subject:=20RE:=20[P2PSIP]=20Battery=20status=20informati on=20to=20diagnostics=20draft|Thread-Topic:=20[P2PSIP]=20 Battery=20status=20information=20to=20diagnostics=20draft |Thread-Index:=20AcoQgPT60bEs64BkSRWIzXTrk0b83QAdHu0w |Message-ID:=20<2D06DE445C2ADE44890118C3F449B9637A3E0AA7@ NASANEXMB12.na.qualcomm.com>|References:=20<048201c9ff81$ 31bace80$0f0ca40a@china.huawei.com>=0D=0A=09<4A703538.505 0702@ee.oulu.fi>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-U S|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5692"=3B=20a=3D"21429461"; bh=hsl/YMbAbAXgUEnBXiDKVO1abYfNt/UlickKxkAeVhs=; b=sRvJGKZav+rYGRIJc0f8OjOuQJtL7N19SSSuGTxluJGxsVtPXUu8JbWQ 7siE5zb2MoTl7YHPlURgHiT/9j1rOzVj874OXO1cItLGEbloKPywq58+e OF5rHkfJWYEGsnsEBykaY1UhjzaEiZkLGNYb8AZyjPb9m9D4YYM2QaWUD M=; X-IronPort-AV: E=McAfee;i="5300,2777,5692"; a="21429461" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jul 2009 02:18:40 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6U9Ieik032483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Jul 2009 02:18:40 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6U9IV5K022613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jul 2009 02:18:31 -0700 (PDT) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.33]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Thu, 30 Jul 2009 02:18:31 -0700 From: "Das, Saumitra" To: jc , Erkki Harjula Date: Thu, 30 Jul 2009 02:18:28 -0700 Thread-Topic: [P2PSIP] Battery status information to diagnostics draft Thread-Index: AcoQgPT60bEs64BkSRWIzXTrk0b83QAdHu0w Message-ID: <2D06DE445C2ADE44890118C3F449B9637A3E0AA7@NASANEXMB12.na.qualcomm.com> References: <048201c9ff81$31bace80$0f0ca40a@china.huawei.com> <4A703538.5050702@ee.oulu.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Battery status information to diagnostics draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 09:19:07 -0000 While this seems a useful option to have to build better overlays; we shoul= d use something that reflects the estimated remaining uptime based on energ= y remaining of a device which is more relevant to overlay operations. Just = energy information may be ambiguous. From a diagnosis point of view we cann= ot deduce what it means. I still think the diagnostic kinds are not defined fully. It wont be very u= seful if each implementation has its own notion of defining bandwidth, proc= essing power etc. Some more explanantion of the kinds would be very useful.= =20 Thanks Saumitra -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= jc Sent: Wednesday, July 29, 2009 12:14 PM To: Erkki Harjula Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Battery status information to diagnostics draft IMHO, this should be a binary value representative of the % of energy =20 a device may have available at any given time. This covers solar, =20 wind, etc and not simply "battery" as far as terminology is concerned. =20 Who's to say a solar based geo-sync satellite might not be running as =20 a p2psip node one day with battery backup on board? ;-) jc On Jul 29, 2009, at 4:40 AM, Erkki Harjula wrote: > Hi, > > as requested in P2PSIP session yesterday, I restate here on the list =20 > my comment regarding battery status information. > > I think including battery status information would be useful to =20 > include in the draft. It would be useful e.g. in peer/client mode =20 > decision or load balancing, where battery status information could =20 > be used to relieve the load of those nodes running on batteries =20 > (just two examples among many others!). As everybody knows, more and =20 > more devices nowadays, especially in P2PSIP scenarios, are battery =20 > operated. > > The status info could be the remaining battery percentage, or simply =20 > a binary value telling whether the node is running on its batteries =20 > or not. > > -Erkki > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From melodysong@huawei.com Thu Jul 30 03:59:28 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFBB28C144 for ; Thu, 30 Jul 2009 03:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnCWx6p8V12J for ; Thu, 30 Jul 2009 03:59:27 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2F17C3A694F for ; Thu, 30 Jul 2009 03:59:08 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL00C35D6BNZ@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 30 Jul 2009 18:58:59 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL003IJD6BWY@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 30 Jul 2009 18:58:59 +0800 (CST) Received: from 975DEF9223E44C7 ([77.241.97.115]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNL00LJ3D667I@szxml01-in.huawei.com>; Thu, 30 Jul 2009 18:58:59 +0800 (CST) Date: Thu, 30 Jul 2009 12:58:51 +0200 From: Song Haibin To: "Das, Saumitra" , jc , Erkki Harjula Message-id: <00fd01ca1104$bc10f610$45012b0a@975DEF9223E44C7> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <048201c9ff81$31bace80$0f0ca40a@china.huawei.com> <4A703538.5050702@ee.oulu.fi> <2D06DE445C2ADE44890118C3F449B9637A3E0AA7@NASANEXMB12.na.qualcomm.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Battery status information to diagnostics draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 10:59:28 -0000 Yes. The difficult thing of including battery status as one kind of diagnostic information is how you define it. I think Saumitra's comment (remaining uptime from the perspective of battery) makes sense. Could you please list all the diagnostic information kinds that are not clear in your mind? So that we can try to fix the definition. Thanks, Haibin ----- Original Message ----- From: "Das, Saumitra" To: "jc" ; "Erkki Harjula" Cc: "'P2PSIP WG'" Sent: Thursday, July 30, 2009 11:18 AM Subject: Re: [P2PSIP] Battery status information to diagnostics draft > While this seems a useful option to have to build better overlays; we should use something that reflects the estimated remaining uptime based on energy remaining of a device which is more relevant to overlay operations. Just energy information may be ambiguous. From a diagnosis point of view we cannot deduce what it means. > > I still think the diagnostic kinds are not defined fully. It wont be very useful if each implementation has its own notion of defining bandwidth, processing power etc. Some more explanantion of the kinds would be very useful. > > Thanks > Saumitra > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of jc > Sent: Wednesday, July 29, 2009 12:14 PM > To: Erkki Harjula > Cc: 'P2PSIP WG' > Subject: Re: [P2PSIP] Battery status information to diagnostics draft > > IMHO, this should be a binary value representative of the % of energy > a device may have available at any given time. This covers solar, > wind, etc and not simply "battery" as far as terminology is concerned. > Who's to say a solar based geo-sync satellite might not be running as > a p2psip node one day with battery backup on board? ;-) > > jc > > On Jul 29, 2009, at 4:40 AM, Erkki Harjula wrote: > >> Hi, >> >> as requested in P2PSIP session yesterday, I restate here on the list >> my comment regarding battery status information. >> >> I think including battery status information would be useful to >> include in the draft. It would be useful e.g. in peer/client mode >> decision or load balancing, where battery status information could >> be used to relieve the load of those nodes running on batteries >> (just two examples among many others!). As everybody knows, more and >> more devices nowadays, especially in P2PSIP scenarios, are battery >> operated. >> >> The status info could be the remaining battery percentage, or simply >> a binary value telling whether the node is running on its batteries >> or not. >> >> -Erkki >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From zongning@huawei.com Thu Jul 30 04:06:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11C63A6BF6 for ; Thu, 30 Jul 2009 04:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.141 X-Spam-Level: X-Spam-Status: No, score=-98.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+cbjeZGhAwm for ; Thu, 30 Jul 2009 04:06:01 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 4C07D3A6A20 for ; Thu, 30 Jul 2009 04:06:01 -0700 (PDT) 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 <0KNL0008LDHSUM@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 30 Jul 2009 19:05:52 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL0062VDHS93@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 30 Jul 2009 19:05:52 +0800 (CST) Received: from z-20684ca876cc4 (dhcp-14d2.meeting.ietf.org [130.129.20.210]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNL00KN9DHOBB@szxml02-in.huawei.com> for p2psip@ietf.org; Thu, 30 Jul 2009 19:05:52 +0800 (CST) Date: Thu, 30 Jul 2009 13:05:57 +0200 From: Ning Zong To: p2psip Message-id: <0KNL00KNADHQBB@szxml02-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: multipart/alternative; boundary="Boundary_(ID_EZGT1cNZPI1p8yR/789A5A)" Subject: [P2PSIP] Fw: [ppsp] updated agenda of PPSP Bar BOF X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 11:06:02 -0000 This is a multi-part message in MIME format. --Boundary_(ID_EZGT1cNZPI1p8yR/789A5A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQoNCiAgDQpIaSxhbGwsDQogICBUaGUgUFBTUCAoUDJQIHN0cmVhbWluZyBwcm90b2NvbCkgZmlu YWwgYmFyIGJvZiBhZ2VuZGEgaXMgdXBkYXRlZCBhcyBmb2xsb3dzLiBXZSBjaGFuZ2UgYSBsaXR0 bGUgdGhlIG9yZGVyIG9mIHRoZSBwcmVzZW50YXRpb24gdG8gbWFrZSB0aGUgcHJvYmxlbSBkaXNj dXNzaW9uIG1vcmUgY29uc2lzdGVudC5Bbnkgc3VnZ2VzdGlvbnMgYW5kIGNvbnRyaWJ1dGlvbnMg YXJlIHdlbGNvbWUuDQogICANCiAgUFBTUCBGaW5hbCBCYXIgQm9GLS0gSUVURiA3NSwgU3RvY2to b2xtDQogIDIwMDAtMjIwMCBUaHVyc2RheSxKdWx5IDMwLFJvb20gMzAwLiANCiAgTWFpbGluZyBs aXN0o7pwcHNwQGlldGYub3JnIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w cHNwDQogIENoYWlyOiBZdW5mZWkgWmhhbmcoIHpoYW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbSkN CiAgICAgICAgICAgIEdvbnphbG8gQ2FtYXJpbGxvICggZ29uemFsby5jYW1hcmlsbG9AZXJpY3Nz b24uY29tKQ0KICAgICAgICAgICAgTmluZyBab25nKHpvbmduaW5nQGh1YXdlaS5jb20pDQogICBB RDogTGFycyBFZ2dlcnQoIGxhcnMuZWdnZXJ0QG5va2lhLmNvbSkgDQogIA0KICANCiAgDQogDQpB Z2VuZGENCjEuIEFnZW5kYSBiYXNoaW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKENoYWlyLDUnKSAgDQoNCjIu IFNob3J0IEludHJvZHVjdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChDaGFpciw1JykNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KMy4gUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChZdW5mZWkgWmhhbmcsIDQwJykNCiAgIGRyYWZ0 LXpoYW5nLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQtMDQgDQoNCiANCjQuIFNvbHV0aW9uIGFuZCBz dXJ2ZXkgZHJhZnRzIA0KIC0tLS1DaHVuayBEaXNjb3ZlcnkgZm9yIFAyUCBTdHJlYW1pbmcgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChOaW5nIFpvbmcsIDIwoa8pIA0KICAgICAgICBk cmFmdC16b25nLXBwc3AtY2h1bmstZGlzY292ZXJ5LTAwIA0KDQogLS0tLSBQcm90b2NvbCBBbmFs eXNpcyBvZiBQUGxpdmUsIFBQU3RyZWFtIGFuZCBVVVNlZSBieSBJbnRlcmVudCBNZWFzdXJlbWVu dCAgICAgICAgICAgICAgICAgICAgICAgICAgIChZdW5mZWkgWmhhbmcsMTAnKQ0KICAgICAgICAg ZHJhZnQtemhhbmctcHBzcC1wcm90b2NvbC1jb21wYXJpc29uLW1lYXN1cmVtZW50LTAyIA0KDQo1 LiBEaXNjdXNzaW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChBbGwsIDMwJykNCiANCjYuIERlY2lzaW9u cyBhbmQgSFVNcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIChBbGwsIDUnKQ0KIA0KNy4gQ29uY2x1c2lvbnMgYW5kIE5leHQgU3RlcHMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChDaGFpcnMv QURzLCA1JykgICANCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg QlINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFl1bmZlaQ0KDQoN Cg0KDQp6aGFuZ3l1bmZlaQ0KMjAwOS0wNy0yOA0K --Boundary_(ID_EZGT1cNZPI1p8yR/789A5A) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8geG1sbnM6c3QxPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1D b250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBj b250ZW50PSJNU0hUTUwgNi4wMC42MDAwLjE2ODA5IiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8 Qk9EWT4NCjxIUj4NCg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIGNvbG9y PSMwMDAwMDA+Jm5ic3A7PC9GT05UPiANCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48 Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5h PjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PEZPTlQgDQpm YWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD48L0RJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0y PjxGT05UIA0KZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEycHQiPjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCAN CmNvbG9yPSMwMDAwMDA+SGksYWxsLDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9E SVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAw PjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgPC9TUEFOPlRo ZSBQUFNQIChQMlAgc3RyZWFtaW5nIHByb3RvY29sKSANCmZpbmFsIGJhciBib2YgYWdlbmRhIGlz IHVwZGF0ZWQgYXMgZm9sbG93cy4gV2UgY2hhbmdlIGEgbGl0dGxlIHRoZSBvcmRlciBvZiB0aGUg DQpwcmVzZW50YXRpb24gdG8gbWFrZSB0aGUgcHJvYmxlbSZuYnNwO2Rpc2N1c3Npb24gbW9yZSBj b25zaXN0ZW50LkFueSBzdWdnZXN0aW9ucyANCmFuZCBjb250cmlidXRpb25zIGFyZSB3ZWxjb21l LjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZP TlQtU0laRTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0j MDAwMDAwPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgDQo8 L1NQQU4+PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHls ZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIA0K Y29sb3I9IzAwMDAwMD4mbmJzcDsmbmJzcDtQUFNQIEZpbmFsIEJhciBCb0YtLSBJRVRGIDc1LCA8 c3QxOkNpdHkgDQp3OnN0PSJvbiI+PHN0MTpwbGFjZSANCnc6c3Q9Im9uIj5TdG9ja2hvbG08L3N0 MTpwbGFjZT48L3N0MTpDaXR5PjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0K PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5n PUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsgPC9TUEFOPjIwMDAtMjIwMCBUaHVyc2RheSxKdWx5IDMwLFJvb20gMzAwLiANCjxv OnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0KbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPk1haWxp bmcgbGlzdDwvRk9OVD48L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogy87M5TsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJyI+o7o8L1NQQU4+PFNQQU4g DQpsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+cHBzcEBpZXRmLm9yZyA8QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wcHNwIj5odHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cHBzcDwvQT48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1T SVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIGNvbG9yPSMwMDAw MDA+Jm5ic3A7IA0KQ2hhaXI6IFl1bmZlaSBaaGFuZyggPC9GT05UPjxBIGhyZWY9Im1haWx0bzp6 aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb20iPjxGT05UIA0KY29sb3I9IzAwMDAwMD56aGFuZ3l1 bmZlaUBjaGluYW1vYmlsZS5jb208L0ZPTlQ+PC9BPjxGT05UIA0KY29sb3I9IzAwMDAwMD4pPC9G T05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCANCmNvbG9yPSMwMDAwMDA+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KR29uemFsbyBDYW1hcmlsbG8gPFU+KCZuYnNwOzwvVT48L0ZPTlQ+PEEgDQpocmVmPSJt YWlsdG86Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tIj48Rk9OVCANCmNvbG9yPSMwMDAw MDA+Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPC9GT05UPjwvQT48Rk9OVCANCmNvbG9y PSMwMDAwMDA+KTwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05U LVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgDQpjb2xvcj0j MDAwMDAwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCk5pbmcgWm9uZyg8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOnpvbmdu aW5nQGh1YXdlaS5jb20iPjxGT05UIA0KY29sb3I9IzAwMDAwMD56b25nbmluZ0BodWF3ZWkuY29t PC9GT05UPjwvQT48Rk9OVCANCmNvbG9yPSMwMDAwMDA+KTwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4g bGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9IzAwMDAwMD4mbmJzcDsmbmJzcDsgDQpBRDogTGFycyBFZ2dlcnQoJm5i c3A7PC9GT05UPjxBIGhyZWY9Im1haWx0bzpsYXJzLmVnZ2VydEBub2tpYS5jb20iPjxGT05UIA0K ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAwPmxhcnMuZWdnZXJ0QG5va2lhLmNv bTwvRk9OVD48L0E+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPikmbmJzcDs8L0ZPTlQ+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4g bGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9IzAwMDAwMD4mbmJzcDsgDQo8L0ZPTlQ+PC9TUEFOPjwvUD48L0RJVj48 L0RJVj48L0RJVj48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9O VD48Rk9OVCANCmZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNp emU9Mj48Rk9OVCBmYWNlPVZlcmRhbmEgDQpzaXplPTI+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9 Mj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIA0KZmFjZT1WZXJkYW5hPjxGT05UIHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIA0KZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAwPiZuYnNwOyA8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPFAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0K c3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9O VCBjb2xvcj0jMDAwMDAwPiZuYnNwOyANCjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BB TiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDs8L1NQQU4+PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+ DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxh bmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxGT05UIA0KY29sb3I9IzAwMDAwMD5BZ2VuZGE8bzpwPjwvbzpwPjwvRk9OVD48L0ZP TlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgY29sb3I9IzAwMDAwMD4xLiANCkFnZW5kYSBiYXNo aW5nPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDs8L1NQ QU4+PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOzwvU1BBTj4o Q2hhaXIsNScpPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOzwv U1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpF OiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDA+PFNQQU4g DQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4g bGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9IzAwMDAwMD48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Mi4gU2hvcnQgDQpJbnRyb2R1Y3Rpb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQooQ2hhaXIsNScpPC9TUEFOPjwvRk9O VD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0Kc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L1NQQU4+PG86cD48L286cD48L0ZPTlQ+PC9GT05U PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIGNvbG9yPSMwMDAwMDA+My4gDQpQcm9ibGVtIFN0YXRl bWVudDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L1NQQU4+PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzwvU1BBTj48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9TUEFOPihZdW5mZWkgDQpaaGFuZywgNDAnKTxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQ QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48 Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0KbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFj ZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+ZHJhZnQtemhhbmctcHBzcC1wcm9i bGVtLXN0YXRlbWVudC0wNDwvRk9OVD48L1NQQU4+PFNQQU4gDQpsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48bzpwPjwvbzpw PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPjwvRk9OVD4mbmJz cDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxT UEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IMvOzOU7IG1zby1hc2Np aS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1oYW5zaS1mb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbiciPjwvU1BBTj48U1BBTiANCmxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+PG86cD48L286cD48L1NQQU4+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPiZuYnNw OzwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDA+NC4gU29sdXRpb24gDQphbmQgc3VydmV5 IGRyYWZ0cyZuYnNwOzwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIGNvbG9yPSMwMDAwMDA+Jm5ic3A7 LS0tLUNodW5rIERpc2NvdmVyeSBmb3IgUDJQIA0KU3RyZWFtaW5nJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7KE5pbmcgDQpab25nLCA8c3QxOmNobWV0Y252IHc6c3Q9Im9uIiBVbml0TmFtZT0ioa8iIFNv dXJjZVZhbHVlPSIxMCIgSGFzU3BhY2U9IkZhbHNlIiANCk5lZ2F0aXZlPSJGYWxzZSIgTnVtYmVy VHlwZT0iMSIgVENTQz0iMCI+MjChrzwvc3QxOmNobWV0Y252PikgPC9GT05UPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1V UyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIA0KY29sb3I9IzAwMDAwMD4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpkcmFmdC16b25nLXBwc3AtY2h1 bmstZGlzY292ZXJ5LTAwJm5ic3A7PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCANCmNvbG9yPSMwMDAwMDA+PC9GT05UPjwvU1BBTj4mbmJz cDs8L1A+PC9GT05UPjwvU1BBTj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPiZuYnNwOy0t LS0gUHJvdG9jb2wgQW5hbHlzaXMgb2YgUFBsaXZlLCBQUFN0cmVhbSBhbmQgVVVTZWUgYnkgDQpJ bnRlcmVudCBNZWFzdXJlbWVudDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L1NQQU4+KFl1bmZlaSBa aGFuZywxMCcpPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05U IGNvbG9yPSMwMDAwMDA+PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvU1BBTj48U1BBTiBs YW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ZHJhZnQtemhhbmctcHBzcC1wcm90 b2NvbC1jb21wYXJpc29uLW1lYXN1cmVtZW50LTAyPC9TUEFOPjxTUEFOIA0KbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBs YW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgY29sb3I9IzAwMDAwMD48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQi PjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIA0K Y29sb3I9IzAwMDAwMD41LjwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFO PjxGT05UIA0KZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5 bGU9IkZPTlQtU0laRTogMTJwdDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgDQpjb2xvcj0jMDAwMDAwPiZuYnNwO0Rpc2N1c3Npb24mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoQWxs LCANCjMwJyk8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBmYWNlPVZlcmRhbmE+ PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0K c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjxGT05UIA0KY29sb3I9IzAwMDAwMD4mbmJzcDs8L0ZPTlQ+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9O VCBjb2xvcj0jMDAwMDAwPjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IG1zby1mb250LWtlcm5pbmc6 IDBwdCI+PG86cD42LiBEZWNpc2lvbnMgDQo8L286cD48L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9 VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6 IDEycHQ7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij5hbmQgDQpIVU1zJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKEFsbCwgNScpPC9GT05UPjwvU1BBTj48L0ZPTlQ+ PC9GT05UPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCANCnNpemU9Mj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQg DQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48Rk9OVCAN CmNvbG9yPSMwMDAwMDA+Jm5ic3A7PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUFMSUdOOiBsZWZ0OyBtc28tcGFnaW5hdGlv bjogd2lkb3ctb3JwaGFuOyB0YWItc3RvcHM6IDQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0 IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQg NTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0IiANCmFsaWduPWxlZnQ+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIGxhbmc9 RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjcu IENvbmNsdXNpb25zIGFuZCBOZXh0IA0KU3RlcHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoQ2hhaXJzL0FEcywg DQo1JykmbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0 Ij48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7PC9TUEFOPjwv U1BBTj48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCmNvbG9yPSMwMDAw MDA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48U1BBTiANCnN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KPFAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIA0KY29sb3I9IzAwMDAwMD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj48L1NQQU4+ PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQpjb2xvcj0jMDAw MDAwPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PFNQQU4gDQpzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkJSPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCAN CmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0Ij48Rk9OVCANCmNvbG9yPSMwMDAwMDA+PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCll1bmZlaTwvU1BBTj48bzpwPjwvbzpwPjwvRk9O VD48L1NQQU4+PC9GT05UPjwvUD48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRElWPjwvRElWPjwvRElW PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAw MDAwMCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIGNv bG9yPSMwMDAwMDAgc2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4 IiBTSVpFPTI+DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0y PnpoYW5neXVuZmVpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 Mj4yMDA5LTA3LTI4PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8SFI+DQo8L0JP RFk+PC9IVE1MPg0K --Boundary_(ID_EZGT1cNZPI1p8yR/789A5A)-- From erkkih@ee.oulu.fi Thu Jul 30 05:40:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE8C28C26D for ; Thu, 30 Jul 2009 05:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYVPSBBP1ApU for ; Thu, 30 Jul 2009 05:40:29 -0700 (PDT) Received: from oulu.fi (ousrvr.oulu.fi [130.231.240.1]) by core3.amsl.com (Postfix) with ESMTP id BF7213A6C61 for ; Thu, 30 Jul 2009 05:40:27 -0700 (PDT) Received: from paju.oulu.fi (paju.oulu.fi [130.231.240.20]) by oulu.fi (8.13.7/8.13.7) with ESMTP id n6UCduoa013508; Thu, 30 Jul 2009 15:39:56 +0300 (EEST) Received: from [127.0.0.1] (paju.oulu.fi [130.231.240.20]) by paju.oulu.fi (8.13.7/8.13.7) with ESMTP id n6UCdtl0004146; Thu, 30 Jul 2009 15:39:56 +0300 (EEST) Message-ID: <4A7194A0.8010607@ee.oulu.fi> Date: Thu, 30 Jul 2009 14:40:00 +0200 From: Erkki Harjula User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Song Haibin References: <048201c9ff81$31bace80$0f0ca40a@china.huawei.com> <4A703538.5050702@ee.oulu.fi> <2D06DE445C2ADE44890118C3F449B9637A3E0AA7@NASANEXMB12.na.qualcomm.com> <00fd01ca1104$bc10f610$45012b0a@975DEF9223E44C7> In-Reply-To: <00fd01ca1104$bc10f610$45012b0a@975DEF9223E44C7> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Battery status information to diagnostics draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:40:31 -0000 The problem with expressing the remaining uptime is the difficulty of defining it. Remaining battery percentage is easy and universal method without any estimation inaccuracy. On the other hand, a boolean value telling whether the node is running on batteries may be enough. If you think about the energy consumption from the user's perspective, he/she is usually interested of it only when his/her device is running on its batteries. Energy saving is important from the first second the device is unplugged from external power source, not only when the battery nearly empty. -Erkki Song Haibin wrote: > Yes. The difficult thing of including battery status as one kind of diagnostic information is how you define it. I think Saumitra's comment (remaining uptime from the perspective of battery) makes sense. > > Could you please list all the diagnostic information kinds that are not clear in your mind? So that we can try to fix the definition. > > Thanks, > Haibin > > > ----- Original Message ----- > From: "Das, Saumitra" > To: "jc" ; "Erkki Harjula" > Cc: "'P2PSIP WG'" > Sent: Thursday, July 30, 2009 11:18 AM > Subject: Re: [P2PSIP] Battery status information to diagnostics draft > > > >> While this seems a useful option to have to build better overlays; we should use something that reflects the estimated remaining uptime based on energy remaining of a device which is more relevant to overlay operations. Just energy information may be ambiguous. From a diagnosis point of view we cannot deduce what it means. >> >> I still think the diagnostic kinds are not defined fully. It wont be very useful if each implementation has its own notion of defining bandwidth, processing power etc. Some more explanantion of the kinds would be very useful. >> >> Thanks >> Saumitra >> >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of jc >> Sent: Wednesday, July 29, 2009 12:14 PM >> To: Erkki Harjula >> Cc: 'P2PSIP WG' >> Subject: Re: [P2PSIP] Battery status information to diagnostics draft >> >> IMHO, this should be a binary value representative of the % of energy >> a device may have available at any given time. This covers solar, >> wind, etc and not simply "battery" as far as terminology is concerned. >> Who's to say a solar based geo-sync satellite might not be running as >> a p2psip node one day with battery backup on board? ;-) >> >> jc >> >> On Jul 29, 2009, at 4:40 AM, Erkki Harjula wrote: >> >> >>> Hi, >>> >>> as requested in P2PSIP session yesterday, I restate here on the list >>> my comment regarding battery status information. >>> >>> I think including battery status information would be useful to >>> include in the draft. It would be useful e.g. in peer/client mode >>> decision or load balancing, where battery status information could >>> be used to relieve the load of those nodes running on batteries >>> (just two examples among many others!). As everybody knows, more and >>> more devices nowadays, especially in P2PSIP scenarios, are battery >>> operated. >>> >>> The status info could be the remaining battery percentage, or simply >>> a binary value telling whether the node is running on its batteries >>> or not. >>> >>> -Erkki >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> From davidbryan@gmail.com Thu Jul 30 09:39:35 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356A028C1CF for ; Thu, 30 Jul 2009 09:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtYULgEOGxIi for ; Thu, 30 Jul 2009 09:39:34 -0700 (PDT) Received: from mail-yx0-f186.google.com (mail-yx0-f186.google.com [209.85.210.186]) by core3.amsl.com (Postfix) with ESMTP id 319FE28C2F0 for ; Thu, 30 Jul 2009 09:39:11 -0700 (PDT) Received: by yxe16 with SMTP id 16so1345478yxe.31 for ; Thu, 30 Jul 2009 09:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Cor/90276KD8BSrTT74eeYX4jYjPgAjyHoVVYqLTpz0=; b=l8k+CZdf3l6zsNaCAHcUIkWh9DhjExKM4r/EvjRbZQI2y392QTOeKnKRSqS9xWgJYm hGbWNVlnjF2bfAgmXCDX+7tFX7O/82niS0PEgcupTGgVL9X6Ci0nMd04TiQyiG3B+UfR n9wRAm8rFawh5tC2yTACO+36k3/rqcz1KvuvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EXwuSr5zsMINmuiMcdxphviQAlyfRCSMNotkkdozdQNe2SGsVb6S+haoC+DYlITHcm HsL+27UfjAWM2Udzdch0hUN39pKKeV88cSsukwH7uSZgVdKJ9haoAbawsVSUxx8bB7rl JIlXCR4IolxyHQPNIpmgbh3rvMiMI+b7z5AzE= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.220.10 with SMTP id s10mr2552961ybg.0.1248971950883; Thu, 30 Jul 2009 09:39:10 -0700 (PDT) In-Reply-To: <4A7194A0.8010607@ee.oulu.fi> References: <048201c9ff81$31bace80$0f0ca40a@china.huawei.com> <4A703538.5050702@ee.oulu.fi> <2D06DE445C2ADE44890118C3F449B9637A3E0AA7@NASANEXMB12.na.qualcomm.com> <00fd01ca1104$bc10f610$45012b0a@975DEF9223E44C7> <4A7194A0.8010607@ee.oulu.fi> Date: Thu, 30 Jul 2009 18:39:10 +0200 X-Google-Sender-Auth: 45b9508f41997fef Message-ID: <8b2769930907300939y5df0f444xd8393cc825ec9344@mail.gmail.com> From: "David A. Bryan" To: Erkki Harjula Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Battery status information to diagnostics draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:39:35 -0000 I think this actually leads to a broader discussion/question of where we document and list all the things that we may want to monitor vs. the mechanisms used to collect/monitor them. How do we as a group want to manage the definitions of these various diagnostic information pieces? Now of course we can register the actual codes for them with IANA, but do we try to capture a large number and define in the diagnostic draft? We need to document somewhere what the information associated with the registration BATTERY (or whatever) means. Do we only specify in the diagnostic draft how to get them (i.e., mechanism only), and use some other document/system to define the various fields we track? There is one set of technical questions about *how* we do diagnostics, and another about *what* we want to be collected/monitored. I'd love to hear thoughts on this...I'm not sure what the best plan is yet, still trying to get my head around the question. David (as individual) On Thu, Jul 30, 2009 at 2:40 PM, Erkki Harjula wrote: > The problem with expressing the remaining uptime is the difficulty of > defining it. Remaining battery percentage is easy and universal method > without any estimation inaccuracy. > > On the other hand, a boolean value telling whether the node is running on > batteries may be enough. If you think about the energy consumption from the > user's perspective, he/she is usually interested of it only when his/her > device is running on its batteries. Energy saving is important from the > first second the device is unplugged from external power source, not only > when the battery nearly empty. > > -Erkki > > > Song Haibin wrote: >> >> Yes. The difficult thing of including battery status as one kind of >> diagnostic information is how you define it. I think Saumitra's comment >> (remaining uptime from the perspective of battery) makes sense. >> Could you please list all the diagnostic information kinds that are not >> clear in your mind? So that we can try to fix the definition. >> >> Thanks, >> Haibin >> >> >> ----- Original Message ----- From: "Das, Saumitra" >> To: "jc" ; "Erkki Harjula" >> Cc: "'P2PSIP WG'" >> Sent: Thursday, July 30, 2009 11:18 AM >> Subject: Re: [P2PSIP] Battery status information to diagnostics draft >> >> >> >>> >>> While this seems a useful option to have to build better overlays; we >>> should use something that reflects the estimated remaining uptime based on >>> energy remaining of a device which is more relevant to overlay operations. >>> Just energy information may be ambiguous. From a diagnosis point of view we >>> cannot deduce what it means. >>> >>> I still think the diagnostic kinds are not defined fully. It wont be very >>> useful if each implementation has its own notion of defining bandwidth, >>> processing power etc. Some more explanantion of the kinds would be very >>> useful. >>> Thanks >>> Saumitra >>> >>> -----Original Message----- >>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf >>> Of jc >>> Sent: Wednesday, July 29, 2009 12:14 PM >>> To: Erkki Harjula >>> Cc: 'P2PSIP WG' >>> Subject: Re: [P2PSIP] Battery status information to diagnostics draft >>> >>> IMHO, this should be a binary value representative of the % of energy a >>> device may have available at any given time. This covers solar, wind, etc >>> and not simply "battery" as far as terminology is concerned. Who's to say a >>> solar based geo-sync satellite might not be running as a p2psip node one >>> day with battery backup on board? ;-) >>> >>> jc >>> >>> On Jul 29, 2009, at 4:40 AM, Erkki Harjula wrote: >>> >>> >>>> >>>> Hi, >>>> >>>> as requested in P2PSIP session yesterday, I restate here on the list my >>>> comment regarding battery status information. >>>> >>>> I think including battery status information would be useful to include >>>> in the draft. It would be useful e.g. in peer/client mode decision or load >>>> balancing, where battery status information could be used to relieve the >>>> load of those nodes running on batteries (just two examples among many >>>> others!). As everybody knows, more and more devices nowadays, especially in >>>> P2PSIP scenarios, are battery operated. >>>> >>>> The status info could be the remaining battery percentage, or simply a >>>> binary value telling whether the node is running on its batteries or not. >>>> >>>> -Erkki >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip >