From stephane@glycon.org Mon Oct 4 23:59:09 2010 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 194893A6CD5 for ; Mon, 4 Oct 2010 23:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3] 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 t6PMCU5xwcsH for ; Mon, 4 Oct 2010 23:59:08 -0700 (PDT) Received: from server.glycon.org (server.glycon.org [67.202.105.191]) by core3.amsl.com (Postfix) with ESMTP id 3DEF53A6B2A for ; Mon, 4 Oct 2010 23:59:08 -0700 (PDT) Received: from [192.168.88.100] (gar13-9-83-156-136-174.fbx.proxad.net [83.156.136.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Stephane Bryant", Issuer "StonyFish Inc." (verified OK)) by server.glycon.org (Postfix) with ESMTPS id 76DE276157 for ; Tue, 5 Oct 2010 02:00:03 -0500 (CDT) Message-ID: <4CAACCF2.1010803@glycon.org> Date: Tue, 05 Oct 2010 09:00:02 +0200 From: =?ISO-8859-1?Q?st=E9phane_bryant?= Organization: StonyFish, Inc User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: p2psip@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] P2PSIP Digest, Vol 45, Issue 7 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, 05 Oct 2010 06:59:09 -0000 Hello, > That's great - thank you. The dissector has been committed to the wireshark trunk. Stephane Bryant StonyFish, Inc > > On Sep 28, 2010, at 7:29 AM, st?phane bryant wrote: > >> Hello, >> >> We have added a ReLOAD wireshark dissector to the wireshark trunk. >> (as bug 5263: >> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5263. >> The patch can be downloaded from the bug page). >> >> St?phane Bryant >> Stonyfish, Inc. >> >> >> >> On 09/08/2010 12:15 PM, st?phane bryant wrote: >>> Hello, >>> >>> We are at the final stages of development for a wireshark ReLOAD >>> dissector, which we will release to the community as soon as it is >>> in a half decent shape. >>> We developed the dissector in a rather blind fashion --that is, by >>> simply following the drafts, as was pleasantly suggested in a previous >>> mail. The probability that a dissector developed that way, without >>> the use of at least a few test vectors, will actually function, is, >>> from experience, pretty close to nil: If anyone can provide us >>> with tcpdump files to test with, the help will be immensely >>> appreciated, will spare us moments of embarrassment and waste of time >>> for the unfortunate early users... >>> >>> thanks >>> St?phane Bryant >>> StonyFish, Inc. >> >> _______________________________________________ >> 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 > > > End of P2PSIP Digest, Vol 45, Issue 7 > ************************************* > From fluffy@cisco.com Thu Oct 7 13:43:16 2010 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 C854C3A6F72 for ; Thu, 7 Oct 2010 13:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.431 X-Spam-Level: X-Spam-Status: No, score=-110.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 l+Bul7OxfaAW for ; Thu, 7 Oct 2010 13:43:15 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 97A013A6E69 for ; Thu, 7 Oct 2010 13:43:15 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQMALPNrUyrRN+J/2dsb2JhbACcXQaFXnGeZJxShUcEhFGFbw X-IronPort-AV: E=Sophos;i="4.57,298,1283731200"; d="scan'208";a="197464744" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 07 Oct 2010 20:44:18 +0000 Received: from dhcp-171-68-21-195.cisco.com (dhcp-171-68-21-195.cisco.com [171.68.21.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o97KiIs0001055; Thu, 7 Oct 2010 20:44:18 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <009d01cb3879$75c341c0$6149c540$%roni@huawei.com> Date: Thu, 7 Oct 2010 13:44:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: <67FD2DEA-7A32-440F-80E7-86BF4483BD5C@cisco.com> References: <20100804003006.AD2CB3A69D1@core3.amsl.com> <009d01cb3879$75c341c0$6149c540$%roni@huawei.com> To: Roni Even X-Mailer: Apple Mail (2.1081) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] comment on draft-ietf-p2psip-base-10.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: Thu, 07 Oct 2010 20:43:16 -0000 Thanks - fixed this. On Aug 10, 2010, at 3:47 , Roni Even wrote: > Hi, > I looked at the text on Direct Return Response in section 5.3.2 found some > typos. > > 1. In the middle of last paragraph > > "This cases it to form a new connection directly to that node" should be > "causes" instead of "cases" > > 2. The last sentence > "The connection MAY be closed at any point but is typically kept open until > until it has noot been used for a signicant period of time or one of the > nodes.." > Has "until" twice, "noot" instead in "not" and "signicant" instead of > "significant". > > Roni > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adranpise@gmail.com Fri Oct 8 11:17:11 2010 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 152F53A693D for ; Fri, 8 Oct 2010 11:17:11 -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 SRm9APx3utge for ; Fri, 8 Oct 2010 11:17:09 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id C2B233A692F for ; Fri, 8 Oct 2010 11:17:09 -0700 (PDT) Received: by pzk6 with SMTP id 6so448317pzk.31 for ; Fri, 08 Oct 2010 11:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=LqRfDVBIDoTlTyjLM5de+uMIZXiuZ1jhWc0U0dGWcPg=; b=uyq7YZpiOb94EsTEC1ivH3qQcVnRFXDUQWFoER1xKMURhGSz+AOLRXjmPhRRrmzEP5 Jn/gGZUC8rgWeJ1oXB5wu9FrIMZ2fYTqigsmU7Blv0ug0OqZfYLVJja0HbzvR05Se2RN +P67M9pL2ViH06G7jPcXU9eiGabbYa5JscylM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Vh5VhRdKzN5em8OK94wEg5k5d8UPGyTA5owvkyTnaHuBURW03Ei3MKfz77ccYavUvb uoDvX2lXLF0ZXGdAsy+mjZy1qK2s9HTjGcJH+rM3oWSABHuhFBw7OmqpKjjhu61je5sZ ZnYy/2JzmEq8DgtRVe4whhHtlGoB20V0Z4p/A= MIME-Version: 1.0 Received: by 10.142.148.3 with SMTP id v3mr2374892wfd.2.1286561894628; Fri, 08 Oct 2010 11:18:14 -0700 (PDT) Received: by 10.142.51.10 with HTTP; Fri, 8 Oct 2010 11:18:14 -0700 (PDT) Date: Fri, 8 Oct 2010 14:18:14 -0400 Message-ID: From: Amit R To: p2psip@ietf.org Content-Type: multipart/alternative; boundary=000e0cd228c8b5fda104921f08a1 Subject: [P2PSIP] RELOAD - implementation of Storage module and message encoder decoder 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, 08 Oct 2010 18:23:05 -0000 --000e0cd228c8b5fda104921f08a1 Content-Type: text/plain; charset=ISO-8859-1 Hello, I have implemented RELOAD storage module and encoder/decoder module for RELOAD store and fetch requests. The source code is available on google code at: https://code.google.com/p/reload-protocol/ Here are some details (both implementation and limitations) of the current implementation: 1. Current work provides implementation of RELOAD Store and Fetch request/response and error messages. 2. It provides implementation of encoder/decoder module for the abovementioned RELOAD messages. 3. It provides implementation of data storage for RELOAD. You can store single value, array entry or dictionary entry in RELOAD storage. However, the current implementation limits the value type contained in each of these entries to string i.e. you can only store string type data in RELOAD storage. 4. The data stored in RELOAD storage is not replicated in this implementation. 5. The access control policies for stored data are not implemented in current project. 6. The Topology plugin module constructs the routing table statically from the input config file and routes messages according to that routing table. It does not allow dynamic addition or removal of nodes from overlay network. 7. The current implementation doesn't address security related issues mentioned in the draft e.g. implementation of Security Block for RELOAD messages, or digitally signing the stored data. Thank you, Amit Ranpise adranpise@gmail.com --000e0cd228c8b5fda104921f08a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I have implemented RELOAD storage module and encoder/decoder module for RELOAD store and fetch requests.=20 The source code is available on google code at:
https://code.google.com/p/= reload-protocol/

Here are some = details (both implementation and limitations) of the current implementation= :
1. Current work provides implementation of RELOAD Store and Fetch request/r= esponse=A0 and error messages.
2. It provides implementation of encoder/decoder mod= ule for the abovementioned=A0 RELOAD messages.
3. It provides implementation of data storage for RELOA= D. You can store=A0 single value, array entry or dictionary entry in RELOAD storage. However, t= he current=A0 implementation limits the value type contained in each of these entries to = string=A0 i.e. you can only store string type data in RELOAD storage.
4. The data = stored in RELOAD storage is not replicated in this implementation.
5. The access control policies for stored data are not implemented in curre= nt project.
6. The Topology plugin module constructs the routing table statically from the input=A0 config file and routes messages according to that routing table. It does not allow dynamic addition or removal of nodes from overlay network.
7. The current implementation doesn't address security related issues=20 mentioned in the draft e.g. implementation of Security Block for RELOAD=20 messages, or digitally signing the stored data.

Th= ank you,
Amit Ranpise
--000e0cd228c8b5fda104921f08a1-- From julian@orchidseed.org Fri Oct 8 18:50:21 2010 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 55D903A63D3 for ; Fri, 8 Oct 2010 18:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.481, 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 7Or9wVk86U-u for ; Fri, 8 Oct 2010 18:50:19 -0700 (PDT) Received: from n15.c05.mtsvc.net (n15.c05.mtsvc.net [70.32.68.15]) by core3.amsl.com (Postfix) with ESMTP id E05583A63C9 for ; Fri, 8 Oct 2010 18:50:18 -0700 (PDT) Received: from 71-22-238-54.gar.clearwire-wmx.net ([71.22.238.54]:47428 helo=[10.0.1.235]) by n15.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1P4Oao-0002DP-2K; Fri, 08 Oct 2010 18:51:24 -0700 References: Message-Id: From: jc To: Amit R In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1--955760965 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 8 Oct 2010 21:51:23 -0400 X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD - implementation of Storage module and message encoder decoder 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, 09 Oct 2010 01:50:21 -0000 --Apple-Mail-1--955760965 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Rockin! On Oct 8, 2010, at 2:18 PM, Amit R wrote: > Hello, > > I have implemented RELOAD storage module and encoder/decoder module > for RELOAD store and fetch requests. The source code is available > on google code at: > https://code.google.com/p/reload-protocol/ > > Here are some details (both implementation and limitations) of the > current implementation: > 1. Current work provides implementation of RELOAD Store and Fetch > request/response and error messages. > 2. It provides implementation of encoder/decoder module for the > abovementioned RELOAD messages. > 3. It provides implementation of data storage for RELOAD. You can > store single value, array entry or dictionary entry in RELOAD > storage. However, the current implementation limits the value type > contained in each of these entries to string i.e. you can only > store string type data in RELOAD storage. > 4. The data stored in RELOAD storage is not replicated in this > implementation. > 5. The access control policies for stored data are not implemented > in current project. > 6. The Topology plugin module constructs the routing table > statically from the input config file and routes messages according > to that routing table. It does not allow dynamic addition or removal > of nodes from overlay network. > 7. The current implementation doesn't address security related > issues mentioned in the draft e.g. implementation of Security Block > for RELOAD messages, or digitally signing the stored data. > > Thank you, > Amit Ranpise > adranpise@gmail.com > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1--955760965 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Rockin!  

On Oct 8, 2010, at 2:18 PM, Amit R <adranpise@gmail.com> wrote:

Hello,

I have implemented RELOAD storage module and encoder/decoder module for RELOAD store and fetch requests. The source code is available on google code at:
https://code.google.com/p/reload-protocol/

Here are some details (both implementation and limitations) of the current implementation:
1. Current work provides implementation of RELOAD Store and Fetch request/response  and error messages.
2. It provides implementation of encoder/decoder module for the abovementioned  RELOAD messages.
3. It provides implementation of data storage for RELOAD. You can store  single value, array entry or dictionary entry in RELOAD storage. However, the current  implementation limits the value type contained in each of these entries to string  i.e. you can only store string type data in RELOAD storage.
4. The data stored in RELOAD storage is not replicated in this implementation.
5. The access control policies for stored data are not implemented in current project.
6. The Topology plugin module constructs the routing table statically from the input  config file and routes messages according to that routing table. It does not allow dynamic addition or removal of nodes from overlay network.
7. The current implementation doesn't address security related issues mentioned in the draft e.g. implementation of Security Block for RELOAD messages, or digitally signing the stored data.

Thank you,
Amit Ranpise
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
--Apple-Mail-1--955760965-- From k_ragab2005@yahoo.com Fri Oct 8 21:56:53 2010 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 CC8CC3A67B7 for ; Fri, 8 Oct 2010 21:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.355 X-Spam-Level: X-Spam-Status: No, score=-0.355 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_NJABL_PROXY=1.643] 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 N7EN6MWmFI9f for ; Fri, 8 Oct 2010 21:56:50 -0700 (PDT) Received: from web54602.mail.re2.yahoo.com (web54602.mail.re2.yahoo.com [206.190.49.172]) by core3.amsl.com (Postfix) with SMTP id 882DE3A657C for ; Fri, 8 Oct 2010 21:56:50 -0700 (PDT) Received: (qmail 21639 invoked by uid 60001); 9 Oct 2010 04:57:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1286600273; bh=msEK4+BwxOqEVZazLneX10lKwDUR6c0BD3vuBkRriRg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=dJpy7Sv/qQ39eOk2MTmo1Gm3j4VftMIFlMTlPGCWfTtSaGP3NwRXLiV9GH/g740GYeNUAr/6mdHKEtR1sYJgI+xScQYN5o8Ixv/tIU4tIlWdhyfHUmTom8Ah37Du+4nrbUA9mInFnU2ZQj1iqiD4r2fzvnLbaWcAQXhS6XxLWmc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=G2HQqWI1xQRZp5wCevXM9F+M70ZvwDFGEvKzKA8FvVfOCN360XoZY14fzZ1zeRlqxewkIX/bWCKT7MWny9hjD74ymX0UetvhtRWBhB59yuKTBho8lLWJDf/g+lziS34VggNyAmBwUBVcfcVQQvLBSXnG+iS330rXkp5LjA+r1B0=; Message-ID: <941616.19854.qm@web54602.mail.re2.yahoo.com> X-YMail-OSG: 3qAZphAVM1l9ZqgkINdLlhifBVtdvuxssdYuYAslnUn3gpv _XxGhA8SWawvcRoeTnR7r1Cl2_R5dXhsoEWIQymP58HO39kFdToek.8LTd25 6iUVn9OjHePgRKQP8sgsuwLwxTqUxXqq5h1AyvDY6Uf7JykyNkoJCnd.j6g. 1DGvIUCFNUyFPIjbNnC3cEFpFqxwJgd_0HScyKW0p8Ou0XwFFE38wQ25oo33 eNl8.PkAqydsnQEmxUudejpaShqJGVUn_ikSm8Aan.QFxK21BKXOBRW.b4ei IEYWmlEEMRqQO87PjTY_QkdO2eXAGSbZWrxTFjBz_fwfa6mwR6Fp022z.kDb Sfz.alKow7X63PSK7TOtsaZeuDb8D Received: from [212.26.27.86] by web54602.mail.re2.yahoo.com via HTTP; Fri, 08 Oct 2010 21:57:53 PDT X-Mailer: YahooMailClassic/11.4.9 YahooMailWebService/0.8.106.282862 Date: Fri, 8 Oct 2010 21:57:53 -0700 (PDT) From: Khaled Ragab To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1890117102-1286600273=:19854" Subject: [P2PSIP] CFC: Wireless Sensor Networks and Energy Efficiency: Protocol, Routing and Management 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, 09 Oct 2010 04:56:54 -0000 --0-1890117102-1286600273=:19854 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Call for book chapters=E2=80=94IGI-Global publisher http://www.igi-global.com/AuthorsEditors/AuthorEditorResources/CallForBookC= hapters/CallForChapterDetails.aspx?CallForContentId=3D1f2c0f38-12ef-4464-ae= 31-30d96b580718=20 Wireless Sensor Networks and Energy Efficiency:=20 Protocols, Routing and Management=20 Editors:=20 Dr. Khaed Ragab=20 King Faisal University, Kingdom of Saudi Arabia=20 =C2=A0=20 Dr. Azween B Abdullah=20 Universiti Teknologi Petronas, Malaysia=20 =C2=A0=20 Noor Zaman=20 King Faisal University, Kingdom of Saudi Arabia=20 Call for Chapters:=20 Proposals Submission Deadline: October 15, 2010=20 Full Chapters Due: December 31, 2010 Introduction=20 =C2=A0=20 Wireless Sensor Network is a very dynamic, grooming and important research = topic of today=E2=80=99s technology. It also provides the finest, cheapest = and the fastest way for solving the typical problems almost for all applica= tion scenarios, including defense, battle fields, health, environmental, in= strumental, home appliances and specially for chemical sites. Designing, im= plementing, and operating a wireless sensor network involves a wide range o= f disciplines and many application-specific constraints. To make sense of a= nd take full advantage of these systems, an excellent approach is needed? A= s WSN is currently playing a major role and also a good segment of research= ers are focusing on this area. Although this field is little bit mature wit= h many aspects but the main issue with this technology is related to its en= ergy constraint, and it is highly important factor as of all operations bas= ed on it. Researchers suggested so many different ways to save its energy, enhance its efficiency and life in different aspects. But it still need to= be consider more, for getting more accurate and precise results by applyin= g new trends and techniques including data routing and aggregation, query p= rocessing, programming models, and system organization. How a wireless sens= or network should be built to optimize performance and economy?=20 =C2=A0=20 Objective of the Book=20 =C2=A0=20 This book aims to provide a comprehensive reference for wireless sensor net= work by covering all important topics introduction, applications, MAC, Rout= ing Protocols, TCP, performance and traffic management, time synchronizatio= n energy efficiency and including security. It will be divided into section= s and with each section, extends the growing literature on the emerging tec= hnologies and innovations would be covered. Thus it would not only serve as= a reference for existing WSN technologies, but it would also become a refe= rence for new innovation in WSN.=20 =C2=A0=20 This editing book has the dual objective of encouraging more research in WS= N technologies and applications and at the same time of publishing the best= research being conducted today. Specifically, we seek to explore how, give= n its current stage of development WSN applications and innovations.=C2=A0= =20 In the past 5 years, there is no an edited book that focuses in merging the= WSN network and system perspectives. There are few edited books that focus= in each perspective individually. However, merging both perspectives gives= a clear view about the current and future development WSN applications and= technologies.=C2=A0=20 =C2=A0=20 Book outline and strategy=20 =C2=A0=20 We will follow the following strategy to edit this book. We decided to spli= t its contents into two parts: The first part is to specify it very strictl= y, basing on personal invitations to carefully chosen researchers, and leav= e the second part open to general chapter submissions. Thus, this book coul= d combine two objectives=20 =E2=80=A2=C2=A0 introducing the WSN Network and system perspectives=20 =E2=80=A2=C2=A0 Exploring and illustrating the current and new trends that = combine them.=20 =C2=A0=20 =C2=A0=20 Target Audience=20 =C2=A0=20 This book would serve a broad audience including researchers, academicians,= students and working professional in the field of utilities, manufacturing= , health, environmental services, government, defense and networking compan= ies.=20 =C2=A0=20 Recommended topics include, but are not limited to, the following:=20 =C2=B7=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 Introduction and Overview of Wireless Sensor Netwo= rks.=C2=A0=20 =C2=B7=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 Transport Control Protocols for Wireless Sensors N= etworks.=C2=A0=20 =C2=B7=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 Middleware for Sensor Networks.=C2=A0=20 =C2=B7=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 Network Management for Wireless Sensor Networks.= =C2=A0=20 =C2=B7=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 Operating Systems for Sensor Networks.=C2=A0=20 =C2=B7=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 Wireless Sensor Network to support Intelligent Tra= nsportation Systems=20 =C2=B7=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 Practical issues in building sensor network applic= ations=20 =C2=B7=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 Commercial and Scientific Applications of Wireless= Sensor Networks.=C2=A0=20 =C2=B7=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 Wireless Sensors Networks Protocols: Physical Laye= r.=C2=A0=20 =C2=B7=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 Performance and Traffic Management Issues.=C2=A0= =20 =C2=B7=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 Broadcasting, Multicasting and Geocasting =C2=A0= =20 =C2=B7=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 Sensor Network Standards=C2=A0=20 =C2=B7=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 Future Trends in Wireless Sensor Network=C2=A0=20 =C2=B7=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 Large scale and Sustainable WSN=20 =C2=B7=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 Node clustering=20 =C2=B7=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 Query Processing and Data Aggregation=C2=A0=20 =C2=B7=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 Node Localization =C2=A0=20 =C2=B7=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 Time Synchronization =C2=A0=20 =C2=B7=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 Energy Efficiency and Power Control =C2=A0=20 =C2=B7=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 Network Security and Attack Defense =C2=A0=20 =C2=B7=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 Medium Access Control MAC Protocols =C2=A0=20 =C2=B7=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 Sensors Network Protocols: Routing Protocols.=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=A0=20 Submission Procedure=20 =C2=A0=20 Researchers, practitioners and professionals are invited to submit on or be= fore October 15, 2010, a chapter proposal, maximum three pages long, clearl= y explaining the topic and objectives of their proposed chapter. Authors of= accepted proposals will be notified by November 1, 2010 about the status o= f their proposals and sent chapter guidelines if the proposal is accepted. = Full chapters are to be submitted by December 31, 2010. All submitted chapt= ers will be reviewed on a double-blind review basis. Contributors may also = be requested to serve as reviewers for this project.=C2=A0=20 =C2=A0=20 Publisher=20 This book is scheduled to be published by IGI Global, publisher of the =E2= =80=9CInformation Science Reference=E2=80=9D (formerly Idea Group Reference= ), =E2=80=9CMedical Information Science Reference,=E2=80=9D =E2=80=9CBusine= ss Science Reference,=E2=80=9D and =E2=80=9CEngineering Science Reference= =E2=80=9D imprints. For additional information regarding the publisher, ple= ase visit www.igi-global.com. This publication is anticipated to be release= d in 2011.=20 =C2=A0=20 =C2=A0=20 Important Dates=20 =C2=A0=20 October 15, 2010:=C2=A0 Chapter proposal submission deadline=20 November 1, 2010: Proposal acceptance notification and invitation to submit= full chapter=20 December 31, 2010: =C2=A0Full chapter submission deadline=20 February 28, 2011: Review results including notification of acceptance of c= hapter=20 March 31, 2011: Final Chapter Submission=20 May 30, 2011: =C2=A0=C2=A0=C2=A0=C2=A0 Final Deadline=20 Inquiries and submissions can be forwarded electronically (Word document):= =20 =C2=A0=20 Noor Zaman=20 nzaman@kfu.edu.sa=C2=A0=20 =C2=A0=20 Dr. Khaled Ragab=20 kabdultawab@kfu.edu.sa=20 =C2=A0=20 Dr. Azween B Abdullah =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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 azweenabdullah@petronas.com.my=0A=0A=0A --0-1890117102-1286600273=:19854 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=0A=0A --0-1890117102-1286600273=:19854-- From michaelc@IDSSOFTWARE.COM Sun Oct 10 21:22:39 2010 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 641843A6407 for ; Sun, 10 Oct 2010 21:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.153 X-Spam-Level: X-Spam-Status: No, score=0.153 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_SUB_ENC_UTF8=0.152] 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 tcbD2O3X3njA for ; Sun, 10 Oct 2010 21:22:38 -0700 (PDT) Received: from smtpoutwbe04.prod.mesa1.secureserver.net (smtpoutwbe04.prod.mesa1.secureserver.net [208.109.78.206]) by core3.amsl.com (Postfix) with SMTP id 97B833A63D3 for ; Sun, 10 Oct 2010 21:22:38 -0700 (PDT) Received: (qmail 18507 invoked from network); 11 Oct 2010 04:23:48 -0000 Received: from unknown (HELO gem-wbe33.prod.mesa1.secureserver.net) (64.202.189.215) by smtpoutwbe04.prod.mesa1.secureserver.net with SMTP; 11 Oct 2010 04:23:47 -0000 Received: (qmail 24961 invoked by uid 99); 11 Oct 2010 04:23:47 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.2.34 Message-Id: <20101010212347.61e8c06078a3b23a733c71e914c0b9df.e398169934.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Sun, 10 Oct 2010 21:23:47 -0700 Mime-Version: 1.0 Subject: [P2PSIP] =?utf-8?q?LeaveReq=2Eleaving=5Fpeer=5Fid?= 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, 11 Oct 2010 04:22:39 -0000 Hi, What is the purpose of LeaveReq.leaving_peer_id? Are we allowing peer-A "inform" peer-B that peer-C has left the overlay? If yes, what kind of access control or security policy govern the sender peer-A? If no, then we should remove this field and mandates that LeaveReq can only be sent from the peer that is actually leaving. Thanks --Michael From julian@orchidseed.org Mon Oct 11 10:55:44 2010 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 CB1EC3A6B28 for ; Mon, 11 Oct 2010 10:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 5MLWXKD0yc+d for ; Mon, 11 Oct 2010 10:55:43 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id E605C3A6A7C for ; Mon, 11 Oct 2010 10:55:43 -0700 (PDT) Received: from 71-22-238-54.gar.clearwire-wmx.net ([71.22.238.54]:47969 helo=[10.0.1.236]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1P5McH-0003Es-BW; Mon, 11 Oct 2010 10:56:55 -0700 References: <20101010212347.61e8c06078a3b23a733c71e914c0b9df.e398169934.wbe@email00.secureserver.net> In-Reply-To: <20101010212347.61e8c06078a3b23a733c71e914c0b9df.e398169934.wbe@email00.secureserver.net> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <47DB2D54-88C7-4C63-A6A4-3FC2B791EEF1@orchidseed.org> X-Mailer: iPhone Mail (8B117) From: jc Date: Mon, 11 Oct 2010 13:56:17 -0400 To: Michael Chen X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] LeaveReq.leaving_peer_id 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, 11 Oct 2010 17:55:44 -0000 I believe it is a leftover parameter that should be removed from the draft. I= t serves no legitimate purpose and opens an exploit where one could flood th= e overlay with phony leave requests not signed by the identifier's owner if h= andled improperly. Julian Cain On Oct 11, 2010, at 12:23 AM, "Michael Chen" wrot= e: > Hi, >=20 > What is the purpose of LeaveReq.leaving_peer_id? Are we allowing peer-A > "inform" peer-B that peer-C has left the overlay? If yes, what kind of > access control or security policy govern the sender peer-A? If no, then > we should remove this field and mandates that LeaveReq can only be sent > from the peer that is actually leaving. >=20 > Thanks >=20 > --Michael >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From ekr@rtfm.com Mon Oct 11 13:03:24 2010 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 EA3283A6B2B for ; Mon, 11 Oct 2010 13:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.726 X-Spam-Level: X-Spam-Status: No, score=-101.726 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 dS5eGn1+22Ni for ; Mon, 11 Oct 2010 13:03:23 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 9F4ED3A6B7C for ; Mon, 11 Oct 2010 13:03:23 -0700 (PDT) Received: by gxk20 with SMTP id 20so1434973gxk.31 for ; Mon, 11 Oct 2010 13:04:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.78.8 with SMTP id a8mr3090286agb.161.1286827474500; Mon, 11 Oct 2010 13:04:34 -0700 (PDT) Received: by 10.91.190.1 with HTTP; Mon, 11 Oct 2010 13:04:34 -0700 (PDT) In-Reply-To: <47DB2D54-88C7-4C63-A6A4-3FC2B791EEF1@orchidseed.org> References: <20101010212347.61e8c06078a3b23a733c71e914c0b9df.e398169934.wbe@email00.secureserver.net> <47DB2D54-88C7-4C63-A6A4-3FC2B791EEF1@orchidseed.org> Date: Mon, 11 Oct 2010 13:04:34 -0700 Message-ID: From: Eric Rescorla To: jc Content-Type: multipart/alternative; boundary=001636283774813d7a04925cdecd Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] LeaveReq.leaving_peer_id 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, 11 Oct 2010 20:03:25 -0000 --001636283774813d7a04925cdecd Content-Type: text/plain; charset=ISO-8859-1 The same issue applies with JoinReq. I noticed it in my last read through and was just about to add a check against the signature. If the WG consensus is to remove these parameters I'm happy to do so. -Ekr On Mon, Oct 11, 2010 at 10:56 AM, jc wrote: > I believe it is a leftover parameter that should be removed from the draft. > It serves no legitimate purpose and opens an exploit where one could flood > the overlay with phony leave requests not signed by the identifier's owner > if handled improperly. > > Julian Cain > > On Oct 11, 2010, at 12:23 AM, "Michael Chen" > wrote: > > > Hi, > > > > What is the purpose of LeaveReq.leaving_peer_id? Are we allowing peer-A > > "inform" peer-B that peer-C has left the overlay? If yes, what kind of > > access control or security policy govern the sender peer-A? If no, then > > we should remove this field and mandates that LeaveReq can only be sent > > from the peer that is actually leaving. > > > > Thanks > > > > --Michael > > > > _______________________________________________ > > 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 > --001636283774813d7a04925cdecd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The same issue applies with JoinReq. I noticed it in my last read through a= nd was
just about to add a check against=A0the signature. If the WG con= sensus is to remove these parameters I'm=A0
happy to do so.

-Ekr


On Mo= n, Oct 11, 2010 at 10:56 AM, jc <julian@orchidseed.org> wrote:
I believe it is a leftover parameter that should be removed from the draft.= It serves no legitimate purpose and opens an exploit where one could flood= the overlay with phony leave requests not signed by the identifier's o= wner if handled improperly.

Julian Cain

On Oct 11, 2010, at 12:23 AM, "Michael Chen" <michaelc@idssoftware.com> wrote:

> Hi,
>
> What is the purpose of LeaveReq.leaving_peer_id? Are we allowing peer-= A
> "inform" peer-B that peer-C has left the overlay? =A0If yes,= what kind of
> access control or security policy govern the sender peer-A? =A0If no, = then
> we should remove this field and mandates that LeaveReq can only be sen= t
> from the peer that is actually leaving.
>
> Thanks
>
> --Michael
>
> _______________________________________________
> 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

--001636283774813d7a04925cdecd-- From fluffy@cisco.com Tue Oct 12 08:10:44 2010 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 8A0743A68E4 for ; Tue, 12 Oct 2010 08:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 RIlKkmbSfGg6 for ; Tue, 12 Oct 2010 08:10:33 -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 4854B3A69C8 for ; Tue, 12 Oct 2010 08:10:31 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOsWtEyrR7Hu/2dsb2JhbAChUnGiEJx8gw4Mgi4EhFKFb4MD X-IronPort-AV: E=Sophos;i="4.57,320,1283731200"; d="scan'208";a="370219628" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2010 15:11:45 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9CFBifM028006; Tue, 12 Oct 2010 15:11:44 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Oct 2010 09:11:44 -0600 Message-Id: <533597E2-DE65-4D15-A3D9-E39F619AB366@cisco.com> To: P2PSIP WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: Eric Burger Subject: [P2PSIP] reload review from eric 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, 12 Oct 2010 15:10:44 -0000 Thanks once again for the review ... comments inline and also thanks to = ekr for updating most of these in the doc. This is changed in next rev = of the draft.=20 > SUBSTANTIVE COMMENTS > Section 5.3.2.1, Processing Configuration Sequence Numbers The > configuration sequence number is a monotonically increasing, 16-bit > integer. Age is determined modulo 65536. That is, 3 is typically > considered newer than 65530. RELOAD uses the sequence number to > determine if a received configuration is newer than the current > configuration. However, the value 65535 is special, in that the > recipient must accept the configuration. This is great, unless a > peer is at configuration sequence 65534. Let us say the peer is > disconnected, and missed the next two updates. Now the global > sequence number is 1. During normal operations, 1 is newer than > 65534. However, the peer will send out its configuration with the > next number in the sequence, 65535. Unfortunately, this is the > special, must accept sequence number, meaning the out-of-date peer's > configuration will overwrite the new configuration. > > I would suggest adding language similar to the following at the end > of the last paragraph in the section: "Since 65535 is a special > value, peers sending a new configuration when the configuration > sequence is currently 65534 MUST set the configuration sequence > number to 0 when they send out a new configuration." Done. > Section 5.3.2.2, Destination and Via Lists > How is it possible to enforce "the encoding MUST include a > generation counter..."? I didn't do that. Nanny nanny boo boo. The > protocol police in the black helicopters will get you if you don't! Removed. > Section 5.4.2.5, Probe > Are there any security or privacy issues exposed by willy-nilly > probe requests, or is the nature of the p2p network to be trusting? > The latter is OK; this is a peer network after all. As far as I know, there are no issues. Do you think this needs to go = into sec cons. > CLARIFYING COMMENTS > Section 1.2, Architecture > Someone unfamiliar with P2P technologies may wonder, "Why are we > defining a message routing protocol? What is wrong with IP? What is > the relation between RELOAD and, for example, MANET? Is all this > routing for NAT traversal? Won't IPv6 make this obsolete?" To be > honest, it was not until I reviewed Section 9 on Chord did message > routing make some sense to me. A bit of clarifying text here or a > forward reference to Section 9 might head off knee-jerk reactions of > "we are not going to standardize IP over P2P over IP." Added some text. > Section 2, Terminology, Resource Name > The text states the resource name is human readable. In this case, > it must have some indication of language and character set. I think "potentially" defuses this objection. > Section 2, Terminology, Connection Table and Routing Table > I read the words in the definitions for these terms, but they made > absolutely no sense to me on the first reading. They make perfect > sense on the second reading. I would almost offer we have some, > "There are circular definitions here; if these definitions do not > make sense to you now, they will after you finish reading this > document in its entirety." That also has the benefit of encouraging > people to actually read the document. Actually, I wonder if we should just move them to the end and define on first introduction. Thoughts? > Section 5.1.3, Private ID > On my first pass, I said to myself, "It looks like a Private ID > could clash with a Node ID." It was not until I ready the pseudo > code defining a Destination that I saw these IDs have their own name > spaces. It would be helpful to say something in 5.1 or 5.1.3 similar > to, "Private IDs have their own, distinct namespace with Node IDs > and Resource IDs." Done. > Section 5.2.1, Request Origination, request timeout > Why a 3 second timer? Satellite IP can have up to 2.5 seconds of > one-way latency. Is this arbitrary? If so, I would think 3 > micro-fortnights would be a better timer (apologies to Dave Oran). > On the serious side, should there not be a relationship between this > timeout and the RTO of Section 5.6.3.1.1? For example, if a > satellite RTO is five sections, an implementation should be able to > adjust this time accordingly. The relation with RTO really only has to do with a single hop in the = overlay so I don't think it should be related to that. The RTO for one = hop might be very fast if both nodes are on the same spaceship and very = slow to the next node that is on a different planet. ABout the best I = can see us being able to do is make this configurable. Should we do = that? > Section 5.2.1, Request Origination, write requests > Assume X and Y have write permissions for a resource. X does a write > that gets lost, then Y does a write, then X retries the write. Who > wins? Y wins. X gets an error. How can I make this clearer? > Section 5.3.1, Presentation Language, style issue > WAY too many adjectives and adverbs that do not add any value. I > would offer it is easy and very familiar to write straightforward > and clear language. I think I addressed this. > Section 5.3.2.1, Forwarding Options [Real Issue] > If RESPONSE_COPY is set, I understand copying the option from the > request to the response. However, the text goes on to say, "and > clear the ... flags." The expected behavior is not clear to me. Not sure what's unclear. I tried to fix a bit. > Section 5.3.3, Message Contents Format > Is there a reason for the alternating request / response codes? If > it is to deal with overlapping responses, then you cannot have > multiple requests with the same point code outstanding. If one can > have multiple requests with the same point codes, then you will need > sequence numbers. If you have sequence numbers, then you do not > need to correlate requests with responses via the request / response > code. The concept of odd / even request / response codes seems a > bit unnecessarily complex. I do have this comment in the CLARIFYING > section as I am sure there is an engineering reason to do odd / even > codes. If there is no reason to do it, than I would put this > comment in the SUBSTANTIVE comment section. IIRC it's the last remaining feature from P2PP. Do you feel strongly that it's bad? > Section 5.3.3, Message Contents Format > If critical =3D False, the recipient SHOULD process the message, > *UNLESS*???? Why would the peer chose not to process the message? > Or, is this really a MAY? Changed to MAY. > Section 5.3.3.1, Response Codes and Response Errors, = Error_Request_Timeout > The text does not make it clear *who* received what, when? Which end = times out? Which end sends the message? I tend to think that this is a stupid error and should just be removed. > Section 5.3.3.1, discussion of Error_Config_Too_New and = Error_Unknown_Kind > It took me three readings to figure out the text says what it means, > but we need better text. The text talks about responses to > messages, which is a message that gets sent. These two response > codes tell the implementor to send this message, then send a > Config_Update message. That is just what we want to do. However, > it took me two readings to understand that Config_Update was not an > error message. The problem is there are way too many "messages" > floating around. In SIP terms, we would say something like send a > Config_Update method. In the context of this document, could we say > something like "A node which generates this response MUST send a > Config_Update request containing the appropriate kind definition > after sending the response."? I fear you have this backward. ConfigTooNew and UnknownKind are sent by a responder and reacted to by the requester (who has the new info). ConfigTooOld is sent by a = responder and followed by an update. I've tried to clarify. > Section 5.5.1.2 > Under what circumstances would a peer not process an Attach request? > If you cannot think if it, then a peer MUST process an Attach > request. The peer can always reject the request. If you can think > of it, like if the peer is under a DoS attack and is purposely > dropping Attach requests, say so. Otherwise, peers MAY process > Attach requests. Fixed. > Also, this paragraph looks like it has a lot of > editing shrapnel. For example, it says the peer needs to start ICE > checks, and then start ICE checks. ICE is so slow as it is, so we > do not need to do it twice. Can you give this another read. The second start refers to the = requester, hence the phrase "receives an Attach response". > Section 5.5.1.4, last paragraph > The text does not describe under what circumstances would a peer not > select a new stun server from the same group? Are you really saying > that a peer MUST select a new STUN server from the same group, > unless there are no STUN servers remaining? Are you really saying > that a peer can pick a STUN server from anywhere, but it is > RECOMMENDED to pick a server from the same group? fixed > Section 5.5.1.6, last bullet > "For example, the DTLS/UDP with SR overlay link protocol." is not a = sentence. Where is the verb? Fixed. > Section 5.5.2.2 - but really a general comment > Most RFC's have the structure Clients do This; Servers do That. I > get this is a peer-to-peer protocol. However, even in a peer > protocol, someone sends a request, and the other end sends a > response. This section, which is where a responder would go, has > lots of directions for the requestor as well. This is begging for > implementor confusion. A constructive comment would be to either > break this out and have the normative language for the requestor to > be in section 5.5.2.1 or have a comment up front warning > implementors to basically look everywhere for the normative protocol > definition. Can you suggest some text and a location for it. > Section 5.5.3.1, Ping Request Definition > Since a Ping can be sent to a ResourceID, should that not also be in > the PingReq? Or will the header take care of ResourceID versus > NodeID addressing? The latter. > Section 6.4.4.1, page 87, first full paragraph after the structure = definition, last sentence. > Should the last line read "and, if not, the peer MUST reject the = request"? Done. > Section 6.4.1.2 > The peer returns the StoreAns, and the text says the response > includes a list of peers where the data will be replicated. This is > where passive voice does not work (by the way, passive voice never > works!): WHO replicates the data? Fixed. > Section 6.1.4.2, KindId definition > The definition is "KindId unknown_kinds<2^8-1>". What does this > mean? Is unknown_kinds an array of fixed length of 127? Is it a > variable length array of zero to 127 entries, "KindId > unknown_kinds<0..2^8-1>"? If the latter, this is a typo. If the > former, the syntax definition does not talk about scalar vectors. Fixed. > Section 6.4.4 > Is the statement "interactively fetching R_n+1=3Dnearest(1 + R_n)" = meaningful to the community? Community ??? Comments ??? Anyone? Brueller, Brueller, ... > Section 9, third from last bullet > Is 2^128 nodes really a limit? Is that not something like making > every quark in the universe a potential peer? Or am I exaggerating > and this is really just the number of atoms in the solar system? Fixed. > Section 10.1, definition of turn-density > Just checking, but if the default value is 1, my read of the > document is that every node is a TURN server. 1/1 =3D 1 =3D 100%. = Along > those lines, what if you wanted, for example in a closed LAN or > enterprise, to have no TURN servers. How would you represent that? > A very large number so 1/large-number is almost zero? Fixed to use 0 to mean infinity=20 > Section 10.1, definition of bad-node > My read of this section is there can be only one bad-node listed at > a time. If I read that wrong, it needs to be more clear that more > than one bad-node can get listed. However, I have another question. > Since NodeID's get allocated or are generated, what if a node gets > NodeID X, the network later says X is a bad-node, and much later a > new node gets assigned NodeID X? Is X forever taken out of the > NodeID name space? If so, that could make for an interesting > denial-of-service attack, that of removing NodeIDs. Conversely, if > bad-node has a life time, the text should talk about it. Given the > large NodeID name space, and that they are not human readable, one > could have a compromise of black listing for a "long, but finite" > time. Fixed. > Section 10.3, Credentials > The text says the Node-IDs need to be "unpredictable to the > requesting user." Is this a redundant requirement to the Node-ID > being cryptographically random? Since the reason for it being > unpredictable is given in the security section, I would either > clarify with text like "The enrollment server must chose Node-IDs > such that they are unpredictable to the requesting user. Thus, the > Node-IDs MUST be cryptographically random [RFC4086]." If I am > wrong, and cryptographically random is not sufficient as to what > "unpredictable to the requesting user" means, then the text must > describe what "unpredictable" means. This isn't redundant. Addressed. > Section 12.3 > Something I am clueless on. The user name looks like a FQDN, like allice@dht.example.net. If it looks like a FQDN, can one resolve the address from outside the peer network? If one can, how? If one cannot, why do we have a string of characters that looks like a FQDN? This is a clarifying question, in that I can get it, but my brain hurts. Hmm - not sure what to do. The FQDN has to do with how the namespace is = allocated not if it is resolvable for or not. Even with email, = alice@cisco-secret-lab-server-inside-the-firewall.cisco.com is not going = to be resolvable outside the split DNS. I think the important things is = .net allocated example to someone that allocated dht to someone that = allocated alice to someone to form a unique name. There e is also the = question about what resolution means related to a separate conversation = on if the reload URI should have a // in it or not. The question comes = down to does resolve mean resolve using DNS or resolve using some = combination of protocols including DNS and RELOAD. Anyway - I have no = idea what we should do here. If you think some text change is needed ... = let me know. From root@core3.amsl.com Tue Oct 12 08:15:03 2010 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7186F3A699E; Tue, 12 Oct 2010 08:15:02 -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: <20101012151503.7186F3A699E@core3.amsl.com> Date: Tue, 12 Oct 2010 08:15:02 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-11.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, 12 Oct 2010 15:15:03 -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-11.txt Pages : 154 Date : 2010-10-12 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 to any documents that update or supersede them. This specification 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-11.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-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12081058.I-D@ietf.org> --NextPart-- From br@brianrosen.net Tue Oct 12 08:38:56 2010 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 69EED3A63EB for ; Tue, 12 Oct 2010 08:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 L-4ov9zrj+0W for ; Tue, 12 Oct 2010 08:38:55 -0700 (PDT) Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by core3.amsl.com (Postfix) with ESMTP id 20FFF3A69C1 for ; Tue, 12 Oct 2010 08:38:55 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.16]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P5gxS-0008CQ-Mm; Tue, 12 Oct 2010 08:40:09 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <533597E2-DE65-4D15-A3D9-E39F619AB366@cisco.com> Date: Tue, 12 Oct 2010 11:40:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6AE15103-67D3-43F7-B3B4-EF2558931D48@brianrosen.net> References: <533597E2-DE65-4D15-A3D9-E39F619AB366@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wwh1.winweblinux.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Eric Burger , P2PSIP WG Subject: Re: [P2PSIP] reload review from eric 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, 12 Oct 2010 15:38:56 -0000 >> Section 12.3 >> Something I am clueless on. The user name looks like a FQDN, like > allice@dht.example.net. If it looks like a FQDN, can one resolve > the address from outside the peer network? If one can, how? If one > cannot, why do we have a string of characters that looks like a > FQDN? This is a clarifying question, in that I can get it, but my > brain hurts. >=20 > Hmm - not sure what to do. The FQDN has to do with how the namespace = is allocated not if it is resolvable for or not. Even with email, = alice@cisco-secret-lab-server-inside-the-firewall.cisco.com is not going = to be resolvable outside the split DNS. I think the important things is = .net allocated example to someone that allocated dht to someone that = allocated alice to someone to form a unique name. There e is also the = question about what resolution means related to a separate conversation = on if the reload URI should have a // in it or not. The question comes = down to does resolve mean resolve using DNS or resolve using some = combination of protocols including DNS and RELOAD. Anyway - I have no = idea what we should do here. If you think some text change is needed ... = let me know. What we want is a unique userid. We don't need an FQDN. Would a URN be = more appropriate? We could even create a namespace for a URN that allowed a "username" and = a "domain name" as components: urn:reload:userid:dht.example.net:alice Brian From ted.ietf@gmail.com Tue Oct 12 12:10:25 2010 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 7A3ED3A6A49 for ; Tue, 12 Oct 2010 12:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, J_CHICKENPOX_72=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 aMDCH4vbGaEv for ; Tue, 12 Oct 2010 12:10:22 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 9B3E53A6A3D for ; Tue, 12 Oct 2010 12:10:22 -0700 (PDT) Received: by qyk8 with SMTP id 8so876861qyk.10 for ; Tue, 12 Oct 2010 12:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L/OhsJTPjtCLtRiuUXzmJ1hM/xhVv2TCaSd4wUmmmsA=; b=uUCWS4+Wa6Qj/G6fwjEOUP/FUKvr8nEuGrYfuTy4tl6rn4UjQhWOmcyNUQcDjeZERX 6F7ldgwwAGb/9+EfnLuFRTUsr3NoOsLqxRC55CYF1dIzIioGMI2MpPGy5xkzghBSBbM9 pqlcajWH5t6qCI1jYylkdGAV+HAcm2DB1kAa0= 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=VkXAT0c5JGLD+vmm1SLwLdnnmD4Lp+cJH5LPeJ5hW/AqaPzxP/Ag4rQ0zOjiBr9+zI 0GEBEBVUeooReIb+8xuYVBRfTLfLlmWf1ZOKiwfSqL/ViHrhLG+hyAw6plSi9P1dHMjK AV3+mFTLPw26iJed95DBdzkRIJ3B0YqkVvxXY= MIME-Version: 1.0 Received: by 10.229.251.16 with SMTP id mq16mr6640246qcb.118.1286910694191; Tue, 12 Oct 2010 12:11:34 -0700 (PDT) Received: by 10.229.213.69 with HTTP; Tue, 12 Oct 2010 12:11:34 -0700 (PDT) In-Reply-To: <6AE15103-67D3-43F7-B3B4-EF2558931D48@brianrosen.net> References: <533597E2-DE65-4D15-A3D9-E39F619AB366@cisco.com> <6AE15103-67D3-43F7-B3B4-EF2558931D48@brianrosen.net> Date: Tue, 12 Oct 2010 12:11:34 -0700 Message-ID: From: Ted Hardie To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Eric Burger , P2PSIP WG Subject: Re: [P2PSIP] reload review from eric 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, 12 Oct 2010 19:10:26 -0000 Some comments inline. On Tue, Oct 12, 2010 at 8:40 AM, Brian Rosen wrote: >>> Section 12.3 >>> Something I am clueless on. =A0The user name looks like a FQDN, like >> =A0allice@dht.example.net. =A0If it looks like a FQDN, can one resolve >> =A0the address from outside the peer network? =A0If one can, how? =A0If = one >> =A0cannot, why do we have a string of characters that looks like a >> =A0FQDN? =A0This is a clarifying question, in that I can get it, but my >> =A0brain hurts. >> >> Hmm - not sure what to do. The FQDN has to do with how the namespace is = allocated not if it is resolvable for or not. Even with email, alice@cisco-= secret-lab-server-inside-the-firewall.cisco.com is not going to be resolvab= le outside the split DNS. I think the important things is .net allocated ex= ample to someone that allocated dht to someone that allocated alice to some= one to form a unique name. There e is also the question about what resoluti= on means related to a separate conversation on if the reload URI should hav= e a // in it or not. =A0The question comes down to does resolve mean resolv= e using DNS or resolve using some combination of protocols including DNS an= d RELOAD. =A0Anyway - I have no idea what we should do here. If you think s= ome text change is needed ... let me know. > > What we want is a unique userid. =A0We don't need an FQDN. =A0Would a URN= be more appropriate? > We could even create a namespace for a URN that allowed a "username" and = a "domain name" as components: > urn:reload:userid:dht.example.net:alice > > Brian I don't think you really want URN, which requires a single namespace authority for the whole namespace (the UUID URN being the one counter example permitted so fa= r). A URI scheme for it would be easier. That would require adjusting the format to include the URI scheme as a prepend(it could re-use existing schemes that were used= as an identifier or mint a new one); I think the same should be done with the node-ids, frankly, as they otherwise are fairly opaque values. The node-id mechanism in the now expired p2p-overlay draft described one way to do that, but there are others. Just my two cents, regards, Ted From davidbryan@gmail.com Wed Oct 13 12:55:52 2010 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 1027A3A69C1 for ; Wed, 13 Oct 2010 12:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.69 X-Spam-Level: X-Spam-Status: No, score=-101.69 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 m8Bn8bRIOAip for ; Wed, 13 Oct 2010 12:55:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CBEDA3A691F for ; Wed, 13 Oct 2010 12:55:50 -0700 (PDT) Received: by wwj40 with SMTP id 40so4651018wwj.13 for ; Wed, 13 Oct 2010 12:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=z0yle4mLvQ5eN1Fa28mwM2Kpy0faU2KprC8sQV5NlBA=; b=QNVnegdeK9LkhQivF0iKknRBn5COvBKjJAdnHC67sfoeh00VA/iRwgqjPQ5jClL37O phSOAVszsCffQUX/6mTeC+SQcdpI6wLaigB1UPcJRllhHpT0WHFwK5CXo1QezorOyciQ vT3tRF/lMgtrEGzES/DPHeqHUtaHhBTcVbOJY= 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=FOtYuWoGkC213fukDx7ndjk+70BqDtdmsO+aJ/2WybJNLGgg+8I8iMknoXdjT1LhRl mvcAwvCBsCd/fkETYML9PBQDZrrKyHA8SbaE4/LO7p/4h4GI03INgzWdf85LZbOGh9B3 iryA42MXrim9BcIox3ZSiP1reLHlUFYDkDPF4= MIME-Version: 1.0 Received: by 10.216.6.149 with SMTP id 21mr411458wen.101.1286999827319; Wed, 13 Oct 2010 12:57:07 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.216.86.78 with HTTP; Wed, 13 Oct 2010 12:57:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Oct 2010 15:57:07 -0400 X-Google-Sender-Auth: IItvlws-ePDKwWxp0Nw98zH20tQ Message-ID: From: "David A. Bryan" To: Amit R Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] RELOAD - implementation of Storage module and message encoder decoder 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, 13 Oct 2010 19:55:52 -0000 Great to see the activity on getting some implementations out there. Thanks for sharing. David On Fri, Oct 8, 2010 at 2:18 PM, Amit R wrote: > Hello, > I have implemented RELOAD storage module and encoder/decoder module for > RELOAD store and fetch requests. The source code is available on google c= ode > at: > https://code.google.com/p/reload-protocol/ > Here are some details (both implementation and limitations) of the curren= t > implementation: > 1. Current work provides implementation of RELOAD Store and Fetch > request/response=A0 and error messages. > 2. It provides implementation of encoder/decoder module for the > abovementioned=A0 RELOAD messages. > 3. It provides implementation of data storage for RELOAD. You can store > single value, array entry or dictionary entry in RELOAD storage. However, > the current=A0 implementation limits the value type contained in each of = these > entries to string=A0 i.e. you can only store string type data in RELOAD > storage. > 4. The data stored in RELOAD storage is not replicated in this > implementation. > 5. The access control policies for stored data are not implemented in > current project. > 6. The Topology plugin module constructs the routing table statically fro= m > the input=A0 config file and routes messages according to that routing ta= ble. > It does not allow dynamic addition or removal of nodes from overlay netwo= rk. > 7. The current implementation doesn't address security related issues > mentioned in the draft e.g. implementation of Security Block for RELOAD > messages, or digitally signing the stored data. > Thank you, > Amit Ranpise > adranpise@gmail.com > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From wwwrun@core3.amsl.com Thu Oct 14 10:00:23 2010 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AA1363A6B3A; Thu, 14 Oct 2010 10:00:16 -0700 (PDT) To: even.roni@huawei.com, dbryan@ethernot.org, jiang.x.f@huawei.com, melodysong@huawei.com From: IETF Secretariat Message-Id: <20101014170023.AA1363A6B3A@core3.amsl.com> Date: Thu, 14 Oct 2010 10:00:16 -0700 (PDT) X-Mailman-Approved-At: Thu, 14 Oct 2010 18:13:31 -0700 Cc: p2psip@ietf.org, housley@vigilsec.com, gonzalo.camarillo@ericsson.com, ipr-announce@ietf.org Subject: [P2PSIP] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-p2psip-diagnostics-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, 14 Oct 2010 17:00:24 -0000 Dear Roni Even, David Bryan, XingFeng Jiang, Song Yongchao: An IPR disclosure that pertains to your Internet-Draft entitled "P2PSIP Overlay Diagnostics" (draft-ietf-p2psip-diagnostics) was submitted to the IETF Secretariat on 2010-10-14 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1427/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-p2psip-diagnostics-04." The IETF Secretariat From sunchw@gmail.com Fri Oct 15 03:38:09 2010 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 A57153A6941 for ; Fri, 15 Oct 2010 03:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=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 Josu19OpYhXH for ; Fri, 15 Oct 2010 03:38:09 -0700 (PDT) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by core3.amsl.com (Postfix) with ESMTP id CFA803A6832 for ; Fri, 15 Oct 2010 03:38:08 -0700 (PDT) Received: by iwn6 with SMTP id 6so364926iwn.27 for ; Fri, 15 Oct 2010 03:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=ZepG+fglSI1abeDYK35AwrvYxBzXKhNOvP1FH5HTNVY=; b=dcq8R4l5Nm3qKgR3ENafL/8M8SrRZphmn+I7HLP7A0sPnxz48/l/9nbI4mwmZtYe54 Iwjbb1dMMNxYxjty41ZtYcRdTNKhrj/jiBh2eAbhWd/nrmH/R+nrEwgnl6z9f4Hq68Yg 2SsbZnBKt938V5DiZOBx5N187yh3f337zCTcI= 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=Ymph/GjNG+ZfxNgi2VX4ztMb1WE8W9FOn1K5Ng/67lRr2EpgwVkRWRKf7dqoKJBGfv myFxZwHajoG244Wh2KgCWxTtOhLA7la2k8lQRI4L27xwWQ1lNrJLbFgC+Uf7Qr2cXbkW uZ3rQERSJXxw0hgrinqgvzVsnB5+InojnLnHE= MIME-Version: 1.0 Received: by 10.231.171.7 with SMTP id f7mr418556ibz.72.1287139169275; Fri, 15 Oct 2010 03:39:29 -0700 (PDT) Received: by 10.231.66.8 with HTTP; Fri, 15 Oct 2010 03:39:29 -0700 (PDT) Date: Fri, 15 Oct 2010 18:39:29 +0800 Message-ID: From: Sun Chongwei To: P2PSIP WG Content-Type: multipart/alternative; boundary=0016369f9dc7f60dc60492a5704a Cc: =?GB2312?B?s8LK6dLl?= , =?GB2312?B?1cW0urrswM/Kpg==?= Subject: [P2PSIP] [p2psip]New draft about security extension 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: Fri, 15 Oct 2010 10:38:09 -0000 --0016369f9dc7f60dc60492a5704a Content-Type: text/plain; charset=ISO-8859-1 Dear all, We have submitted a new Internet draft entitled "Public Security Channel(PSC): An Alternative Key Management Mode in RELOAD" It can be accessed at: http://www.ietf.org/id/draft-chen-p2psip-psc-00.txt Any comments are welcome. Abstract: REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol for use on the Internet. This document proposes a security extension for RELOAD. A new data transmission security model was introduced in this draft. This model was based on a central Key Management Server (KMS). Security communications among multi peers can be achieved with PSC(Public Security Channel). PSC can also get performance improvement compared with TLS/DTLS method in RELAOD draft. -- Sun Chongwei Mobile LIfe and New Media Lab Beijing University of Posts and Telecommunications --0016369f9dc7f60dc60492a5704a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

We have submitted a new Internet draft entitled "= ;Public Security Channel(PSC): An Alternative Key Management Mode in RELOAD= "
It can be accessed at:=A0 http://www.ietf.org/id/draft-chen-p2psip-psc-00.tx= t
Any comments are welcome.

Abstract:
REsource LOcation And Discovery (RELOAD) is a peer-to-pe= er (P2P)
signaling protocol for use on the Internet. This document propo= ses a
security extension for RELOAD. A new data transmission security mo= del
was introduced in this draft. This model was based on a central Key
Mana= gement Server (KMS). Security communications among multi peers
can be ac= hieved with PSC(Public Security Channel). PSC can also get
performance i= mprovement compared with TLS/DTLS method in
RELAOD draft.


--
Sun Chongwei
Mobile LIfe= and New Media Lab
Beijing University of Posts and Telecommunications
--0016369f9dc7f60dc60492a5704a-- From gabriel-mailinglists@gmx.de Sat Oct 16 07:48:38 2010 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 B86FA3A68E1 for ; Sat, 16 Oct 2010 07:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[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 PrYDyFLPzJ8c for ; Sat, 16 Oct 2010 07:48:37 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id BE9053A67A3 for ; Sat, 16 Oct 2010 07:48:36 -0700 (PDT) Received: (qmail invoked by alias); 16 Oct 2010 14:49:58 -0000 Received: from e178139045.adsl.alicedsl.de (EHLO [192.168.1.5]) [85.178.139.45] by mail.gmx.net (mp072) with SMTP; 16 Oct 2010 16:49:58 +0200 X-Authenticated: #1873484 X-Provags-ID: V01U2FsdGVkX19VOA9k7fBV5ATK/JeQp3ANVOoTjfhKNHi8hnUcwf +82vuocEGtICg9 Message-ID: <4CB9BB66.70100@gmx.de> Date: Sat, 16 Oct 2010 16:49:10 +0200 From: Gabriel Hege User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Sun, 17 Oct 2010 05:43:39 -0700 Subject: [P2PSIP] draft-ietf-p2psip-base: Objects signed by the storing peer? 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, 16 Oct 2010 14:48:38 -0000 Hi! I just stumbled accross the following sentence in section 1.3 "Security" in the current version of the RELOAD draft: Stored objects must be signed by the *storing peer*. My understanding is, that the "storing peer" is the one responsible for the Resource Id under which an object will be stored. So it should probably say something like: Stored objects must be signed by the creating peer. best regards, Gabriel -- [ Gabriel Hege http://inet.cpt.haw-hamburg.de/members/hege ] [ AG INET, Dept. Informatik ] [ Hamburg University of Applied Sciences Fon: +49 40 42875-8067 ] [ Berliner Tor 7, D-20099 Hamburg, Germany Fax: +49 40 42875-8409 ] From peng.yonglin@zte.com.cn Sun Oct 17 18:25:42 2010 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 76A133A6C53 for ; Sun, 17 Oct 2010 18:25:42 -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_74=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 rJHnte4K-xqu for ; Sun, 17 Oct 2010 18:25:41 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C78993A6C49 for ; Sun, 17 Oct 2010 18:25:39 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205952075036648; Mon, 18 Oct 2010 09:24:33 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.2075036648; Mon, 18 Oct 2010 09:27:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9I1Qw4O000704 for ; Mon, 18 Oct 2010 09:26:58 +0800 (CST) (envelope-from peng.yonglin@zte.com.cn) To: P2PSIP WG MIME-Version: 1.0 X-KeepSent: 79547365:41BDCB87-482577C0:00048346; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.yonglin@zte.com.cn Date: Mon, 18 Oct 2010 09:26:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-18 09:26:53, Serialize complete at 2010-10-18 09:26:53 Content-Type: multipart/alternative; boundary="=_alternative 0007E99F482577C0_=" X-MAIL: mse3.zte.com.cn o9I1Qw4O000704 Cc: hao.zhenwu@zte.com.cn, wang.wei108@zte.com.cn, meng.yu@zte.com.cn Subject: [P2PSIP] New draft about an SNMP 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, 18 Oct 2010 01:25:43 -0000 This is a multipart message in MIME format. --=_alternative 0007E99F482577C0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0ZWQgYSBuZXcgZHJhZnQ6IEFuIFNOTVAgVXNhZ2Ug Zm9yIFJFTE9BRC4gSXQgaXMgYXQgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtcGVu Zy1wMnBzaXAtc25tcC0wMC50eHQuDQoNCkFueSBjb21tZW50cyBhcmUgd2VsY29tZSEgDQoNCg0K RmlsZW5hbWU6ICAgICAgICAgICAgICAgICBkcmFmdC1wZW5nLXAycHNpcC1zbm1wDQpSZXZpc2lv bjogICAgICAgICAgICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgICAgICAgICAgICAgICAgICAg QW4gU05NUCBVc2FnZSBmb3IgUkVMT0FEDQpDcmVhdGlvbl9kYXRlOiAgICAgICAgICAgIDIwMTAt MTAtMTUNCk51bWJlcl9vZl9wYWdlczogMTINCg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IGRl ZmluZXMgYSBTTk1QIFVzYWdlIGZvciBSRXNvdXJjZSBMT2NhdGlvbiBBbmQNCkRpc2NvdmVyeShS RUxPQUQpLCBUaGUgU05NUCBVc2FnZSBwcm92aWRlcyB0aGUgZnVuY3Rpb25hbGl0eSBvZg0KbWFu YWdpbmcgdGhlIFJFTE9BRCBuZXR3b3JrLiAgVGhlIFNOTVAgVXNhZ2UgcHJvdmlkZXMgbG9va3Vw IHNlcnZpY2UNCmZvciB0aGUgbmV0d29yayBtYW5hZ2VyJ3MgYWRkcmVzcyBzdG9yZWQgaW4gdGhl IG92ZXJsYXkuICBUaGUgU05NUA0KVXNhZ2UgYWxzbyBkZWZpbmVzIHRoZSBtZXRob2QgdGhhdCBh bGxvdyB0aGUgcmVnaXN0cmF0aW9ucyB0byBtYXAgYQ0KbmV0d29yayBtYW5hZ2VyJ25hbWUgdG8g YSBzcGVjaWZpYyBub2RlIHJlYWNoYWJsZSB0aHJvdWdoIHRoZQ0Kb3ZlcmxheS4gIFRoZSBBcHBB dHRhY2ggbWV0aG9kIGlzIHVzZWQgdG8gZXN0YWJsaXNoIGEgZGlyZWN0DQpjb25uZWN0aW9uIGJl dHdlZW4gbm9kZXMgdGhyb3VnaCB3aGljaCBTTk1QIG1lc3NhZ2VzIGFyZSBleGNoYW5nZWQuDQoN ClRoYW5rcw0KDQpQZW5nIFlvbmdMaW4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0K08ogvP6junBlbmcueW9uZ2xpbkB6dGUuY29tLmNuDQrE2iDP 36O6ODgxOTANCs3iIM/fo7owMjUtNTI4NzgxOTANCsrWILv6o7oxMzc3NjYzNzI3NA0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0007E99F482577C0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgYWxsLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2UgaGF2ZSBzdWJtaXRlZCBh IG5ldyBkcmFmdDogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+QW4NClNO TVAgVXNhZ2UgZm9yIFJFTE9BRC4gSXQgaXMgYXQgPC9mb250PjxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1wZW5nLXAycHNpcC1zbm1wLTAwLnR4dCI+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1wZW5nLXAycHNpcC1zbm1wLTAwLnR4dDwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5BbnkgY29tbWVudHMgYXJlIHdlbGNvbWUhICZuYnNwOzwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjx0dD48Zm9udCBz aXplPTI+RmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXBlbmctcDJwc2lwLXNubXA8YnI+DQpSZXZpc2lv bjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7MDA8YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkFuIFNOTVAgVXNhZ2UgZm9yIFJFTE9BRDxi cj4NCkNyZWF0aW9uX2RhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzIwMTAtMTAtMTU8YnI+DQpOdW1iZXJfb2ZfcGFnZXM6 IDEyPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgU05N UCBVc2FnZSBmb3IgUkVzb3VyY2UgTE9jYXRpb24gQW5kPGJyPg0KRGlzY292ZXJ5KFJFTE9BRCks IFRoZSBTTk1QIFVzYWdlIHByb3ZpZGVzIHRoZSBmdW5jdGlvbmFsaXR5IG9mPGJyPg0KbWFuYWdp bmcgdGhlIFJFTE9BRCBuZXR3b3JrLiAmbmJzcDtUaGUgU05NUCBVc2FnZSBwcm92aWRlcyBsb29r dXAgc2VydmljZTxicj4NCmZvciB0aGUgbmV0d29yayBtYW5hZ2VyJ3MgYWRkcmVzcyBzdG9yZWQg aW4gdGhlIG92ZXJsYXkuICZuYnNwO1RoZSBTTk1QPGJyPg0KVXNhZ2UgYWxzbyBkZWZpbmVzIHRo ZSBtZXRob2QgdGhhdCBhbGxvdyB0aGUgcmVnaXN0cmF0aW9ucyB0byBtYXAgYTxicj4NCm5ldHdv cmsgbWFuYWdlciduYW1lIHRvIGEgc3BlY2lmaWMgbm9kZSByZWFjaGFibGUgdGhyb3VnaCB0aGU8 YnI+DQpvdmVybGF5LiAmbmJzcDtUaGUgQXBwQXR0YWNoIG1ldGhvZCBpcyB1c2VkIHRvIGVzdGFi bGlzaCBhIGRpcmVjdDxicj4NCmNvbm5lY3Rpb24gYmV0d2VlbiBub2RlcyB0aHJvdWdoIHdoaWNo IFNOTVAgbWVzc2FnZXMgYXJlIGV4Y2hhbmdlZC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5QZW5nIFlvbmdMaW48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8YnI+DQrTyiC8/qO6cGVuZy55b25nbGluQHp0ZS5jb20u Y248YnI+DQrE2iDP36O6ODgxOTA8YnI+DQrN4iDP36O6MDI1LTUyODc4MTkwPGJyPg0KytYgu/qj ujEzNzc2NjM3Mjc0PGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKjwvZm9udD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7 U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250 YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJz cDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRp b24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtj b25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDth cmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNw O2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xv c2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmlj YXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNw O2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDth cmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZu YnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2Fy ZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZl ZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJz cDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtt ZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0 aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJz cDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtT cGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0007E99F482577C0_=-- From br@brianrosen.net Mon Oct 18 06:56:50 2010 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 51C6E3A67AD for ; Mon, 18 Oct 2010 06:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 ZWpJM3w6el72 for ; Mon, 18 Oct 2010 06:56:49 -0700 (PDT) Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by core3.amsl.com (Postfix) with ESMTP id 6BF513A69DB for ; Mon, 18 Oct 2010 06:56:49 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.53]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P7qED-0006Qk-8M for p2psip@ietf.org; Mon, 18 Oct 2010 06:58:17 -0700 From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Oct 2010 09:58:12 -0400 Message-Id: To: P2PSIP WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wwh1.winweblinux.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: [P2PSIP] WGLC on draft-ietf-p2psip-base-11 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, 18 Oct 2010 13:56:50 -0000 This message starts a 3 week Working Group Last Call of = draft-ietf-p2psip-base-11. The WGLC will end just prior to our meeting = at IETF79. Please review the document and send comments to the list. Brian= From davidbryan@gmail.com Mon Oct 18 07:13:12 2010 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 235E13A6A56 for ; Mon, 18 Oct 2010 07:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.71 X-Spam-Level: X-Spam-Status: No, score=-101.71 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5I17wCJVUmFK for ; Mon, 18 Oct 2010 07:13:11 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id CA33D3A6AF1 for ; Mon, 18 Oct 2010 07:13:10 -0700 (PDT) Received: by wyb29 with SMTP id 29so1317087wyb.31 for ; Mon, 18 Oct 2010 07:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OqA3i/JrbcgDAwU9Jeyl7JwKEXCN0c1FlBuNjSR1CuM=; b=bWUP8bRityd9r0YvvGGuZ69JR85EHjhIXkIbRFNYsL1Y9YHj+rzlqSr+O6Zq/xQERQ p3hHpVajP0FFRrbQLNnwpIa+EtdmE8bXFLnrtmg++bZ2u3e12DMsOzLloFAm+fprWgwn X+NLGkjXRaOehCpYNDm3pl0hgOl/PJWhSuFxI= 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; b=GmKYNH9redecuVpigINyjkjO8lcLjtJy7cUHRiIovB/VcbFSGGO59iyasW11thX/hq L+qwBms2bqQkuOhDlEUb8eEbBQI3kPsBFFK2Bt7S5ix5q18yIm1VZWtbkjyChOPDwcIj Se9lTPCshxRSq8cWTMjWVHuzxHz78uj0diKyM= MIME-Version: 1.0 Received: by 10.216.59.18 with SMTP id r18mr4658797wec.42.1287411278319; Mon, 18 Oct 2010 07:14:38 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.216.139.14 with HTTP; Mon, 18 Oct 2010 07:14:38 -0700 (PDT) Date: Mon, 18 Oct 2010 10:14:38 -0400 X-Google-Sender-Auth: PVk2yAxahxV0RZd5jc70tL6g1a4 Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Agenda Requests for P2PSIP at IETF-79 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, 18 Oct 2010 14:13:12 -0000 Folks, Please send requests for agenda slots to BOTH chairs by Oct. 25 (also the -01 deadline) to request a slot. As with many other groups this time, to facilitate session participation by non-English speakers, please note the following policies: 1. If a presenter does not submit initial slides by end of day Friday (November 5) before the IETF meeting, the presentation slot will be removed from the agenda. 2. If a presenter does not provide final slides 24 hours before the WG session, we will use their initial slides. We are scheduled for 9:00 Monday, so that deadline would be 9:00 Sunday. Just a reminder that -00 drafts are due TODAY by 15:00 PDT, and -01 drafts are due by 15:00 PDT on 10/25. Thanks, and see you all in Beijing! David (as chair) From frederic.metz@gmail.com Sat Oct 23 00:29:37 2010 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 617323A6955 for ; Sat, 23 Oct 2010 00:29:37 -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 tm7W6fjyKs5E for ; Sat, 23 Oct 2010 00:29:36 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 190AC3A69C9 for ; Sat, 23 Oct 2010 00:29:32 -0700 (PDT) Received: by eyd10 with SMTP id 10so846150eyd.31 for ; Sat, 23 Oct 2010 00:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=Ev63LUPnUqE+uZ1lSYMzeec7wi9r//XzDGOutkAxn/E=; b=bNZTtThgVvtmCsh/BAL+mjHNRO6UGkEFhkckeXHPYr9+1xE/lPDoqXusVgF500XM5G mqvmc0xIUXptx22eUlrmD9wYLr428jRTnFD/taHi5gU4qecRqWlM6A0n+bBhyyoSpqYK Cedkv9eMOUPqHiAsljCVMkBOx0uXx6NdsibJU= 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=SGD+xA+TpKpZkzpefMKnFQzvt38zBH9StEKKvzhI3r1ESy0QuPgDKcG5TEdAjEgNwo 2nX2Zd4e5hvSBE27OuDm4I8/GlW9w/3Za3CkL8pXMH8JdGaYxLUvOCNsoZBwtfYIMMIM 3FEWXX+y7S9WljUd3OrqOPDZ2p5nEDp8Twwig= MIME-Version: 1.0 Received: by 10.213.98.78 with SMTP id p14mr175397ebn.54.1287819071981; Sat, 23 Oct 2010 00:31:11 -0700 (PDT) Received: by 10.213.104.143 with HTTP; Sat, 23 Oct 2010 00:31:11 -0700 (PDT) Date: Sat, 23 Oct 2010 09:31:11 +0200 Message-ID: From: Frederic-Philippe Metz To: P2PSIP@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [P2PSIP] Clarification of initial attach procedure 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, 23 Oct 2010 07:29:37 -0000 Hi all, I've got a question resp. page 123: The first attach in the call flow diagram states JP as the destination. I think it should be AP ? JP has got the node-id of AP from a previous ping, right ? If that assumption is not right, the attach to node-id JP will fail, because 5.5.1 states that the attach to a node-id which isn't reached will fail. Cheers, Fr=E9d=E9ric From julian@orchidseed.org Sat Oct 23 00:42:50 2010 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 16E463A6849 for ; Sat, 23 Oct 2010 00:42:50 -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=-0.261, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 YuasRkRPY7FN for ; Sat, 23 Oct 2010 00:42:49 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 6BCBB3A67A6 for ; Sat, 23 Oct 2010 00:42:49 -0700 (PDT) Received: from 71-22-238-54.gar.clearwire-wmx.net ([71.22.238.54]:49055 helo=[10.0.1.236]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1P9YmB-0005Wd-JW; Sat, 23 Oct 2010 00:44:29 -0700 References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <2D29D389-ECB0-4C9B-8DF8-B36E983D5338@orchidseed.org> X-Mailer: iPhone Mail (8B117) From: jc Date: Sat, 23 Oct 2010 03:43:50 -0400 To: Frederic-Philippe Metz X-Authenticated-User: 72798 julian@orchidseed.org Cc: "P2PSIP@ietf.org" Subject: Re: [P2PSIP] Clarification of initial attach procedure 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, 23 Oct 2010 07:42:50 -0000 It should be AP. You are correct however JP could have discovered the node-i= d of AP through many means. On Oct 23, 2010, at 3:31 AM, Frederic-Philippe Metz wrote: > Hi all, >=20 > I've got a question resp. page 123: >=20 > The first attach in the call flow diagram states JP as the > destination. I think it should be AP ? JP has got the node-id of AP > from a previous ping, right ? If that assumption is not right, the > attach to node-id JP will fail, because 5.5.1 states that the attach > to a node-id which isn't reached will fail. >=20 > Cheers, > Fr=C3=A9d=C3=A9ric > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From frederic.metz@gmail.com Sat Oct 23 09:45:13 2010 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 D9E043A68F7 for ; Sat, 23 Oct 2010 09:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=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 xSFQhsfXnjiL for ; Sat, 23 Oct 2010 09:45:12 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 9D55D3A68DB for ; Sat, 23 Oct 2010 09:45:12 -0700 (PDT) Received: by eyd10 with SMTP id 10so941483eyd.31 for ; Sat, 23 Oct 2010 09:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sTOxWIJWp5eM5blT5WJIedeCKfEQ7ChtFdymOMOLaLY=; b=HPYS41944a3qhUR954iUZNxCFljA2kzluFEa9+D4WbySdeA3l70kZq5fSQZYbckP0y P5HYyH5/k7CVLFeLBnqfoSOyR6JUPg8YxcvgeeOGqDkKKcfPjV1/4nZd5jkNIlvmZgMv x3OySUJW9LBSCsicMfqBuI199uB4VKtJL02tk= 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 :content-type:content-transfer-encoding; b=RAo/APQcUJzbMuKvP8lSDZciLXZslYDsB77kUJOEz7iVwY4Maimo5QBcdAdpMbwlu4 pIukLOjp22DHFsW+Y/tITRbvULN8cD+D+PHCHEBGdBDqh+r72puwzaYZtjgackt6h0X1 TW6zLdfYfJQENgfhjRnlyPFQ1hZYjIi5907Pc= MIME-Version: 1.0 Received: by 10.213.104.133 with SMTP id p5mr4372740ebo.77.1287852411225; Sat, 23 Oct 2010 09:46:51 -0700 (PDT) Received: by 10.213.104.143 with HTTP; Sat, 23 Oct 2010 09:46:51 -0700 (PDT) In-Reply-To: <2D29D389-ECB0-4C9B-8DF8-B36E983D5338@orchidseed.org> References: <2D29D389-ECB0-4C9B-8DF8-B36E983D5338@orchidseed.org> Date: Sat, 23 Oct 2010 18:46:51 +0200 Message-ID: From: Frederic-Philippe Metz To: P2PSIP@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [P2PSIP] Clarification of initial attach procedure 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, 23 Oct 2010 16:45:13 -0000 Hi jc, thanks a lot for the support. Ok, I understand. So the second paragraph in section 10.5 is also not correct ? The init setup procedure, assume you have chord-reload, is where I have problems to understand. Assume the config-server is contacted and the bootstrap IP is in place. What happens then ? I guess the JP a) has to establish a TLS connection to the bootstrap peer. Then b) it has to send an attach to the bootstrap peer for the purpose of sending further RELOAD messages (i.e. ping to find the AP). But from where does it know the Node-Id (for sending the attach request) of the bootstrap peer (in case of central enrollment when the node-id is generated by the enrollment server) ? Second question is for clarification: The draft states a difference between the Connection Table and the Routing table. So I see the Connection Table (in the Forwarding and LinkLayer) as a map of key node-id with value of a IP:Port pair. Would that go along with the draft ? And the Routing table (in the Topology plugin) as an Overlay specific "decision table" to which _node-id_ at the end the message has to be routed. This node-id in the Routing table has always a key entry in the connection table. Would that also go along with the draft ? Cheers, Fr=E9d=E9ric On Sat, Oct 23, 2010 at 9:43 AM, jc wrote: > It should be AP. You are correct however JP could have discovered the nod= e-id of AP through many means. > > On Oct 23, 2010, at 3:31 AM, Frederic-Philippe Metz wrote: > >> Hi all, >> >> I've got a question resp. page 123: >> >> The first attach in the call flow diagram states JP as the >> destination. I think it should be AP ? JP has got the node-id of AP >> from a previous ping, right ? If that assumption is not right, the >> attach to node-id JP will fail, because 5.5.1 states that the attach >> to a node-id which isn't reached will fail. >> >> Cheers, >> Fr=E9d=E9ric >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > From julian@orchidseed.org Sat Oct 23 11:05:55 2010 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 884DF3A68A8 for ; Sat, 23 Oct 2010 11:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.127 X-Spam-Level: X-Spam-Status: No, score=-1.127 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MIME_QP_LONG_LINE=1.396] 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 bZamyVSHEtto for ; Sat, 23 Oct 2010 11:05:54 -0700 (PDT) Received: from n16.c05.mtsvc.net (n16.c05.mtsvc.net [70.32.68.16]) by core3.amsl.com (Postfix) with ESMTP id AB3193A6868 for ; Sat, 23 Oct 2010 11:05:54 -0700 (PDT) Received: from 71-22-238-54.gar.clearwire-wmx.net ([71.22.238.54]:39732 helo=[10.0.1.236]) by n16.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1P9iV7-0000SF-Q0; Sat, 23 Oct 2010 11:07:35 -0700 References: <2D29D389-ECB0-4C9B-8DF8-B36E983D5338@orchidseed.org> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <4040312B-0267-49B5-A3FC-148CBCF9C55C@orchidseed.org> X-Mailer: iPhone Mail (8B117) From: jc Date: Sat, 23 Oct 2010 14:06:52 -0400 To: Frederic-Philippe Metz X-Authenticated-User: 72798 julian@orchidseed.org Cc: "P2PSIP@ietf.org" Subject: Re: [P2PSIP] Clarification of initial attach procedure 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, 23 Oct 2010 18:05:55 -0000 On Oct 23, 2010, at 12:46 PM, Frederic-Philippe Metz wrote: > Hi jc, thanks a lot for the support. Ok, I understand. So the second > paragraph in section 10.5 is also not correct ? >=20 > The init setup procedure, assume you have chord-reload, is where I > have problems to understand. >=20 > Assume the config-server is contacted and the bootstrap IP is in > place. What happens then ? I guess the JP a) has to establish a TLS > connection to the bootstrap peer. Then b) it has to send an attach to > the bootstrap peer for the purpose of sending further RELOAD messages > (i.e. ping to find the AP). But from where does it know the Node-Id > (for sending the attach request) of the bootstrap peer (in case of > central enrollment when the node-id is generated by the enrollment > server) ? The Node-Id is obtained from the message signature. >=20 > Second question is for clarification: > The draft states a difference between the Connection Table and the > Routing table. So I see the Connection Table (in the Forwarding and > LinkLayer) as a map of key node-id with value of a IP:Port pair. Would > that go along with the draft ? And the Routing table (in the Topology > plugin) as an Overlay specific "decision table" to which _node-id_ at > the end the message has to be routed. This node-id in the Routing > table has always a key entry in the connection table. Would that also > go along with the draft ? This sounds like a implementer detail. >=20 > Cheers, > Fr=C3=A9d=C3=A9ric >=20 >=20 > On Sat, Oct 23, 2010 at 9:43 AM, jc wrote: >> It should be AP. You are correct however JP could have discovered the nod= e-id of AP through many means. >>=20 >> On Oct 23, 2010, at 3:31 AM, Frederic-Philippe Metz wrote: >>=20 >>> Hi all, >>>=20 >>> I've got a question resp. page 123: >>>=20 >>> The first attach in the call flow diagram states JP as the >>> destination. I think it should be AP ? JP has got the node-id of AP >>> from a previous ping, right ? If that assumption is not right, the >>> attach to node-id JP will fail, because 5.5.1 states that the attach >>> to a node-id which isn't reached will fail. >>>=20 >>> Cheers, >>> Fr=C3=A9d=C3=A9ric >>> _______________________________________________ >>> 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 frederic.metz@gmail.com Sun Oct 24 02:41:26 2010 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 B91C73A679F for ; Sun, 24 Oct 2010 02:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_24=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 gALxAL0cMMG7 for ; Sun, 24 Oct 2010 02:41:25 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 156CE3A67F3 for ; Sun, 24 Oct 2010 02:41:24 -0700 (PDT) Received: by ewy27 with SMTP id 27so1180590ewy.31 for ; Sun, 24 Oct 2010 02:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=EtOr8yfiQiLCpgsW5zTZKfbbGH++yZwxnciN9xf9gDc=; b=XirFKa1cvNBwy1krUSGGKEzB0RN2YbISdX1ousKmyXqScxeJEEZKfK9Io6hwXW1FR8 2CgA2jFUF5OyCYKC3QLJEay0Z6qN9t1hZdM4lbsplGWJ1hFRKyHbZKyqg3aeJzFRM1Mv U7VJbpneQuQmh6zJhG59J5BwIxtd3piTOnFsE= 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 :content-type:content-transfer-encoding; b=O2FsIUNL3Mq9achoQf9vE8VEBhOEMbE4e1zACAUpH3k6/HdrbdajZaitbwQHxyAI8/ FTFjcXlVOQjr3Q+nTMKiJMHqGmE0h19jf73B/hFctZAIFpSym+OejCP5y8Eq8mqo/P+B 3u38LCZiNo7LdZRqfaHzuzKJZRhqJ/CLxTgkc= MIME-Version: 1.0 Received: by 10.213.11.16 with SMTP id r16mr951366ebr.56.1287913385267; Sun, 24 Oct 2010 02:43:05 -0700 (PDT) Received: by 10.213.104.143 with HTTP; Sun, 24 Oct 2010 02:43:05 -0700 (PDT) In-Reply-To: <4040312B-0267-49B5-A3FC-148CBCF9C55C@orchidseed.org> References: <2D29D389-ECB0-4C9B-8DF8-B36E983D5338@orchidseed.org> <4040312B-0267-49B5-A3FC-148CBCF9C55C@orchidseed.org> Date: Sun, 24 Oct 2010 11:43:05 +0200 Message-ID: From: Frederic-Philippe Metz To: P2PSIP@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [P2PSIP] Clarification of initial attach procedure 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, 24 Oct 2010 09:41:26 -0000 Hi, I didn't catch it, sorry. Do you mean that the node_id is learned at JP via the TLS (certificate) authentication with bootstrap peer ? So when TLS happens, Jp gets the node_id of bootstrap peer via the certificate used in TLS ? That means that for debugging purpose you have to use TLS ? We hoped during implementation that we could use simple TCP connections first, instead of TLS. If so, don't you think that the exchange of the Node_id should better be placed on RELOAD-Layer, not on the Link Layer ? Cheers, Fr=E9d=E9ric On Sat, Oct 23, 2010 at 8:06 PM, jc wrote: > > On Oct 23, 2010, at 12:46 PM, Frederic-Philippe Metz wrote: > >> Hi jc, thanks a lot for the support. Ok, I understand. So the second >> paragraph in section 10.5 is also not correct ? >> >> The init setup procedure, assume you have chord-reload, is where I >> have problems to understand. >> >> Assume the config-server is contacted and the bootstrap IP is in >> place. What happens then ? I guess the JP a) has to establish a TLS >> connection to the bootstrap peer. Then b) it has to send an attach to >> the bootstrap peer for the purpose of sending further RELOAD messages >> (i.e. ping to find the AP). But from where does it know the Node-Id >> (for sending the attach request) of the bootstrap peer (in case of >> central enrollment when the node-id is generated by the enrollment >> server) ? > > The Node-Id is obtained from the message signature. > >> >> Second question is for clarification: >> The draft states a difference between the Connection Table and the >> Routing table. So I see the Connection Table (in the Forwarding and >> LinkLayer) as a map of key node-id with value of a IP:Port pair. Would >> that go along with the draft ? And the Routing table (in the Topology >> plugin) as an Overlay specific "decision table" to which _node-id_ at >> the end the message has to be routed. This node-id in the Routing >> table has always a key entry in the connection table. Would that also >> go along with the draft ? > > This sounds like a implementer detail. > >> >> Cheers, >> =A0Fr=E9d=E9ric >> >> >> On Sat, Oct 23, 2010 at 9:43 AM, jc wrote: >>> It should be AP. You are correct however JP could have discovered the n= ode-id of AP through many means. >>> >>> On Oct 23, 2010, at 3:31 AM, Frederic-Philippe Metz wrote: >>> >>>> Hi all, >>>> >>>> I've got a question resp. page 123: >>>> >>>> The first attach in the call flow diagram states JP as the >>>> destination. I think it should be AP ? JP has got the node-id of AP >>>> from a previous ping, right ? If that assumption is not right, the >>>> attach to node-id JP will fail, because 5.5.1 states that the attach >>>> to a node-id which isn't reached will fail. >>>> >>>> Cheers, >>>> Fr=E9d=E9ric >>>> _______________________________________________ >>>> 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 peng.yonglin@zte.com.cn Mon Oct 25 00:04:49 2010 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 3A5DE3A672F; Mon, 25 Oct 2010 00:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.579 X-Spam-Level: X-Spam-Status: No, score=-94.579 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 M4I2P+FVqutV; Mon, 25 Oct 2010 00:04:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3509C3A67C3; Mon, 25 Oct 2010 00:04:47 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35103559614510; Mon, 25 Oct 2010 15:05:08 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 74518.5680175289; Mon, 25 Oct 2010 15:03:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9P74o4V058317; Mon, 25 Oct 2010 15:04:55 +0800 (CST) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: To: Frederic-Philippe Metz MIME-Version: 1.0 X-KeepSent: DB3AD4B6:2A8A4707-482577C7:00253972; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.yonglin@zte.com.cn Date: Mon, 25 Oct 2010 15:04:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-25 15:04:42, Serialize complete at 2010-10-25 15:04:42 Content-Type: multipart/alternative; boundary="=_alternative 0026D7AE482577C7_=" X-MAIL: mse2.zte.com.cn o9P74o4V058317 Cc: P2PSIP@ietf.org, p2psip-bounces@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogIENsYXJpZmljYXRpb24gb2YgaW5pdGlhbCBh?= =?gb2312?b?dHRhY2ggcHJvY2VkdXJl?= 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, 25 Oct 2010 07:04:49 -0000 This is a multipart message in MIME format. --=_alternative 0026D7AE482577C7_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSB0aGluayBKUCBpcyBjb3JyZWN0LiBUaGUgTm9kZSBvZiBKUCBpcyBhcyBSZXNvdXJjZS1JRCBp biBBdHRhY2guIEJlZm9yZSANCkF0dGFjaGluZywgYSBQaW5nIG1lc3NhZ2UgaXMgcmVkdW5kYW50 LiANCg0KVGhlcmUgaXMgdGhlIGRlc2NyaXB0aW9uIGFib3ZlIHRoZSBzZWNvbmQgZGlyZ3JhbSBp biB0aGUgZHJhZnQ6IA0KIkl0IHNlbmRzIGFuIEF0dGFjaCB0byB0aGUgUmVzb3VyY2UtSVAgQVAr MSwgd2hpY2ggZ2V0cyByb3V0ZWQgdG8gTlAuIg0KDQoiUmVzb3VyY2UtSVAiIHNob3VsZCBiZSAi UmVzb3VyY2UtSUQiLg0KDQoNCg0KDQoNCkZyZWRlcmljLVBoaWxpcHBlIE1ldHogPGZyZWRlcmlj Lm1ldHpAZ21haWwuY29tPiANCuWPkeS7tuS6ujogIHAycHNpcC1ib3VuY2VzQGlldGYub3JnDQoy MDEwLTEwLTIzIDE1OjMxDQoNCuaUtuS7tuS6ug0KUDJQU0lQQGlldGYub3JnDQrmioTpgIENCg0K 5Li76aKYDQpbUDJQU0lQXSBDbGFyaWZpY2F0aW9uIG9mIGluaXRpYWwgYXR0YWNoIHByb2NlZHVy ZQ0KDQoNCg0KDQoNCg0KSGkgYWxsLA0KDQpJJ3ZlIGdvdCBhIHF1ZXN0aW9uIHJlc3AuIHBhZ2Ug MTIzOg0KDQpUaGUgZmlyc3QgYXR0YWNoIGluIHRoZSBjYWxsIGZsb3cgZGlhZ3JhbSBzdGF0ZXMg SlAgYXMgdGhlDQpkZXN0aW5hdGlvbi4gSSB0aGluayBpdCBzaG91bGQgYmUgQVAgPyBKUCBoYXMg Z290IHRoZSBub2RlLWlkIG9mIEFQDQpmcm9tIGEgcHJldmlvdXMgcGluZywgcmlnaHQgPyBJZiB0 aGF0IGFzc3VtcHRpb24gaXMgbm90IHJpZ2h0LCB0aGUNCmF0dGFjaCB0byBub2RlLWlkIEpQIHdp bGwgZmFpbCwgYmVjYXVzZSA1LjUuMSBzdGF0ZXMgdGhhdCB0aGUgYXR0YWNoDQp0byBhIG5vZGUt aWQgd2hpY2ggaXNuJ3QgcmVhY2hlZCB3aWxsIGZhaWwuDQoNCkNoZWVycywNCkZyw6lkw6lyaWMN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQMlBTSVAg bWFpbGluZyBsaXN0DQpQMlBTSVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcDJwc2lwDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0026D7AE482577C7_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgSlAgaXMgY29ycmVj dC4gVGhlIE5vZGUgb2YgSlANCmlzIGFzIFJlc291cmNlLUlEIGluIEF0dGFjaC4gQmVmb3JlIEF0 dGFjaGluZywgYSBQaW5nIG1lc3NhZ2UgaXMgcmVkdW5kYW50Lg0KPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVyZSBpcyB0aGUgZGVzY3JpcHRpb24g YWJvdmUgdGhlIHNlY29uZA0KZGlyZ3JhbSBpbiB0aGUgZHJhZnQ6IDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZxdW90O0l0IHNlbmRzIGFuIEF0dGFjaCB0byB0 aGUgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ291cmllciBOZXciPjxiPlJl c291cmNlLUlQPC9iPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPg0KQVAr MSwgd2hpY2ggZ2V0cyByb3V0ZWQgdG8gTlAuJnF1b3Q7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij5SZXNvdXJjZS1JUDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+JnF1b3Q7DQpzaG91bGQgYmUgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+JnF1b3Q7UmVzb3VyY2UtSUQmcXVvdDsuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkZyZWRlcmljLVBoaWxpcHBl IE1ldHoNCiZsdDtmcmVkZXJpYy5tZXR6QGdtYWlsLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+5Y+R5Lu25Lq6OiAmbmJzcDtwMnBzaXAtYm91 bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y MDEwLTEwLTIzIDE1OjMxPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlAyUFNJUEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 5oqE6YCBPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7kuLvpopg8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltQMlBTSVBdIENsYXJpZmlj YXRpb24gb2YgaW5pdGlhbCBhdHRhY2gNCnByb2NlZHVyZTwvZm9udD48L3RhYmxlPg0KPGJyPg0K PHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxl Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGkgYWxsLDxicj4NCjxicj4NCkkn dmUgZ290IGEgcXVlc3Rpb24gcmVzcC4gcGFnZSAxMjM6PGJyPg0KPGJyPg0KVGhlIGZpcnN0IGF0 dGFjaCBpbiB0aGUgY2FsbCBmbG93IGRpYWdyYW0gc3RhdGVzIEpQIGFzIHRoZTxicj4NCmRlc3Rp bmF0aW9uLiBJIHRoaW5rIGl0IHNob3VsZCBiZSBBUCA/IEpQIGhhcyBnb3QgdGhlIG5vZGUtaWQg b2YgQVA8YnI+DQpmcm9tIGEgcHJldmlvdXMgcGluZywgcmlnaHQgPyBJZiB0aGF0IGFzc3VtcHRp b24gaXMgbm90IHJpZ2h0LCB0aGU8YnI+DQphdHRhY2ggdG8gbm9kZS1pZCBKUCB3aWxsIGZhaWws IGJlY2F1c2UgNS41LjEgc3RhdGVzIHRoYXQgdGhlIGF0dGFjaDxicj4NCnRvIGEgbm9kZS1pZCB3 aGljaCBpc24ndCByZWFjaGVkIHdpbGwgZmFpbC48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KRnLD qWTDqXJpYzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KUDJQU0lQIG1haWxpbmcgbGlzdDxicj4NClAyUFNJUEBpZXRmLm9yZzxicj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPGJyPg0KPGJyPg0KPC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1Nl Y3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFp bmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7 cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9u LiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29u ZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJl Jm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDth bmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3Nl Jm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDth bnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJl Jm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJz cDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUm bmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQm bmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7 bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVz c2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhp cyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7 YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3Bh bSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0026D7AE482577C7_=-- From frederic.metz@gmail.com Mon Oct 25 00:34:23 2010 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 860853A67DA for ; Mon, 25 Oct 2010 00:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.249 X-Spam-Level: * X-Spam-Status: No, score=1.249 tagged_above=-999 required=5 tests=[AWL=-3.448, BAYES_00=-2.599, 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 YXni2vEQV9IK for ; Mon, 25 Oct 2010 00:34:22 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id ACCC13A67BD for ; Mon, 25 Oct 2010 00:34:20 -0700 (PDT) Received: by eyd10 with SMTP id 10so1322409eyd.31 for ; Mon, 25 Oct 2010 00:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Xq5MOuimAASjWlWLm8bbJqbr1yYnKXlrspmZLVwi9Uw=; b=ZM8BgMZeaJccMEMCYTYBCIGhTGfhMufhAMMbiXsClTLVOMc0WlCP8kWt0rO0JduFgh rM1QR5YZ8g3Pcb+FJFnuuuhBpwce4JyNB77IQqx9A12xXdW+7KcdbF5Ddq8hW0Ct9m2Z +WR2rzIOGTAxNet/1x2k3BaPsWnaDGPU2ihps= 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 :content-type; b=L01g6lvFQMkh+OdXojlaBbLTxuTBh/0b+NRut2lAYhqP0s5jUfae0WjGi/Hyo2UBVL HIsYLRwNcrQ4VrWzmKMorY4H4px6/cKR+3qGQeYMgJX/xb3c0oV3gum/vtOUbR11oVnS zGMfHNskl6U+OQrk5S/1fIFXFRLKsvPN4ABTc= MIME-Version: 1.0 Received: by 10.213.2.197 with SMTP id 5mr1607301ebk.64.1287992164522; Mon, 25 Oct 2010 00:36:04 -0700 (PDT) Received: by 10.213.104.143 with HTTP; Mon, 25 Oct 2010 00:36:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Oct 2010 09:36:04 +0200 Message-ID: From: Frederic-Philippe Metz To: p2psip@ietf.org Content-Type: multipart/alternative; boundary=0015174c1d00709c8404936c0bbb Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogIENsYXJpZmljYXRpb24gb2YgaW5pdGlhbCBh?= =?gb2312?b?dHRhY2ggcHJvY2VkdXJl?= 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, 25 Oct 2010 07:34:23 -0000 --0015174c1d00709c8404936c0bbb Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Ok. So JP either can a) Send a ping to the resource id+1 (as the node_id of JP) to get the node-id (in the RELOAD message signature of the Ping answer) to then perfor= m an attach to this node_id (this is mentioned in 9.4) or b) directly form a resource-id+1 (as JP's node_id) and send an attach. Do you agree ? Cheers, Frederic On Mon, Oct 25, 2010 at 9:04 AM, wrote: > > I think JP is correct. The Node of JP is as Resource-ID in Attach. Before > Attaching, a Ping message is redundant. > > There is the description above the second dirgram in the draft: > "It sends an Attach to the *Resource-IP* AP+1, which gets routed to NP." > > "Resource-IP" should be "Resource-ID". > > > > > *Frederic-Philippe Metz * > =B7=A2=BC=FE=C8=CB: p2psip-bounces@ietf.org > > 2010-10-23 15:31 > =CA=D5=BC=FE=C8=CB > P2PSIP@ietf.org > =B3=AD=CB=CD > =D6=F7=CC=E2 > [P2PSIP] Clarification of initial attach procedure > > > > > Hi all, > > I've got a question resp. page 123: > > The first attach in the call flow diagram states JP as the > destination. I think it should be AP ? JP has got the node-id of AP > from a previous ping, right ? If that assumption is not right, the > attach to node-id JP will fail, because 5.5.1 states that the attach > to a node-id which isn't reached will fail. > > Cheers, > Fr=A8=A6d=A8=A6ric > _______________________________________________ > 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. > > --0015174c1d00709c8404936c0bbb Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Ok. So JP either can
a) Send a ping to the resource id+1 (as the node_id= of JP) to get the node-id (in the RELOAD message signature of the Ping ans= wer) to then perform an attach to this node_id (this is mentioned in 9.4) o= r
b) directly form a resource-id+1 (as JP's node_id) and send an attach.<= br>
Do you agree ?

Cheers,
    Frederic
On Mon, Oct 25, 2010 at 9:04 AM, <peng.yonglin@zte.com.cn= > wrote:

I think JP is correct. The Node of= JP is as Resource-ID in Attach. Before Attaching, a Ping message is redundant.

There is the description above the= second dirgram in the draft:
"It sends an Attach to the <= /font>Resource-IP AP+1, which gets routed to NP."

"Resource-IP&qu= ot; should be "Resource-ID&qu= ot;.




Call for book chapters=E2=80= =94IGI-Global publisher

http://www.igi-global.com/AuthorsE= ditors/AuthorEditorResources/CallForBookChapters/CallForChapterDetails.aspx= ?CallForContentId=3D1f2c0f38-12ef-4464-ae31-30d96b580718<= FONT size=3D3>

Wireless Sensor Networks and Energy Efficiency:

Protocols, Routing and Management

Editors:

Dr. Khaed Ragab =

King Faisal University, Kingdom of Saudi Arabia <= o:p>

 

Dr. Azween B Abdullah =

Universiti Teknologi Petronas, Malaysia

 

Noor Zaman

KingFaisal University, Kingdom of Saudi Arabia<= /st1:PlaceName> =



Call for Chapters:
Proposal= s Submission Deadline: October 15, 2010
Full Chapters Due: December 31,= 2010

Introduction= <= /o:p>

 

Wire= less Sensor Network is a very dynamic, grooming and important re= search topic of today=E2=80=99s technology. It also provides the finest, ch= eapest and the fastest way for solving the typical problems almost for all = application scenarios, including defense, battle fields, health, environmen= tal, instrumental, home appliances and specially for chemical sites. Design= ing, implementing, and operating a wireless sensor network involves a wide = range of disciplines and many application-specific constraints. To make sen= se of and take full advantage of these systems, an excellent approach is ne= eded? As WSN is currently playing a major role and also a good segment of r= esearchers are focusing on this area. Although this field is little bit mature with m= any aspects but the main issue with this technology is related to its energ= y constraint, and it is highly important factor as of all operations based = on it. Researchers suggested so many different ways to save its energy, enh= ance its efficiency and life in different aspects. But it still need to be = consider more, for getting more accurate and precise results by applying ne= w trends and techniques including data routing and aggregation, query proce= ssing, programming models, and system organization. How a wireless sensor n= etwork should be built to optimize performance and economy? =

 

Objective of the Book

 

This book aims to provide a comprehensive reference for = wireless sensor network by covering all important topics introduction, appl= ications, MAC, Routing Protocols, TCP, performance and traffic management, = time synchronization energy efficiency and including security. It will be d= ivided into sections and with each section, extends the growing literature = on the emerging technologies and innovations would be covered. Thus it woul= d not only serve as a reference for existing WSN technologies, but it would= also become a reference for new innovation in WSN.

 

This editing book has the dual objective of encouraging = more research in WSN technologies and applications and at the same time of = publishing the best research being conducted today. Specifically, we seek t= o explore how, given its current stage of development WSN applications and = innovations. 

In the past 5 years, there is no an edited book that foc= uses in merging the WSN network and system perspectives. There are few edit= ed books that focus in each perspective individually. However, merging both= perspectives gives a clear view about the current and future development W= SN applications and technologies. 

 

Book outline and strategy

 

We will follow the following strategy to edit this book.= We decided to split its contents into two parts: The first part is to spec= ify it very strictly, basing on personal invitations to carefully chosen re= searchers, and leave the second part open to general chapter submissions. T= hus, this book could combine two objectives

=E2=80=A2  introducing the WSN Network and system pe= rspectives

=E2=80=A2  Exploring and illustrating the current an= d new trends that combine them.

 

 

Target Audience <= o:p>

 

This book would serve a broad audience including researc= hers, academicians, students and working professional in the field of utili= ties, manufacturing, health, environmental services, government, defense an= d networking companies.

 

Recommended topics include<= SPAN style=3D"FONT-FAMILY: Arial; COLOR: black; FONT-SIZE: 9pt">, but are n= ot limited to, the following:

=C2=B7         <= /FONT>        Introduction and Overview of = Wireless Sensor Networks. 

=C2=B7         <= /FONT>        Transport Control Protocols f= or Wireless Sensors Networks. 

=C2=B7         <= /FONT>        Middleware for = Sensor Networks. =

=C2=B7         <= /FONT>        Network Management for Wireless Sensor Networks. 

=C2=B7         <= /FONT>        Operating Systems for Sensor = Networks. 

=C2=B7         <= /FONT>        Wireless Sensor Network to su= pport Intelligen= t Transportation Systems

=C2=B7         <= /FONT>        Practical issues in building = sensor network applications =

=C2=B7         <= /FONT>        Commercial and Scientific App= lications of Wireless Sensor Networks. 

=C2=B7         <= /FONT>        Wireless Sensors Networks Pro= tocols: Physical Layer. 

=C2=B7         <= /FONT>        Performance and Traffic Manag= ement Issues. 

=C2=B7         <= /FONT>        Broadcasting, Multicasting an= d Geocasting  

=C2=B7         <= /FONT>        Sensor Network Standards = ;

=C2=B7         <= /FONT>        Future Trends in Wireless Sen= sor Network 

=C2=B7         <= /FONT>        Large scale and Sustainable W= SN

=C2=B7         <= /FONT>        Node clustering =C2=B7         <= /FONT>        Query Processing and Data Agg= regation 

=C2=B7         <= /FONT>        Node Localization  

=C2=B7         <= /FONT>        Time Synchronization  

=C2=B7         <= /FONT>        Energy Efficiency and Power C= ontrol  

=C2=B7         <= /FONT>        Network Security and Attack D= efense  

=C2=B7         <= /FONT>        Medium Access Control<= /SPAN> MAC Protocols   =

=C2=B7         <= /FONT>        Sensors Network Protocols: Ro= uting Protocols. =             &n= bsp;  

Submission Procedure  

Researchers, practitioners and professionals are invited= to submit on or before October 15, 2010, a chapter proposal, maximum thr= ee pages long, clearly explaining the topic and objectives of their propose= d chapter. Authors of accepted proposals will be notified by November 1<= B>, 2010<= /SPAN>= about the status of their proposals and sent chapter guidelines if the pro= posal is accepted. Full chapters are to be submitted by December 31, 2010. All su= bmitted chapters will be reviewed on a double-blind review basis. Contribut= ors may also be requested to serve as reviewers for this project. 

 

Publisher

This book is scheduled to be published by IGI Global, pu= blisher of the =E2=80=9CInformation Science Reference=E2=80=9D (formerly Id= ea Group Reference), =E2=80=9CMedical Information Science Reference,=E2=80=9D =E2=80= =9CBusiness Science Reference,=E2=80=9D and =E2=80=9CEngineering Science Reference= =E2=80=9D imprints. For additional information regarding the publisher, ple= ase visit www.igi-gl= obal.com. This publication is anticipated to be released in 2011.

 

 

Important Dates <= o:p>

 

=

February 28



Inquiries and submissions can be= forwarded electronically (Word document):

 

Noor Zama= n

nzaman@kfu.edu.sa 

 

<= SPAN style=3D"COLOR: black; FONT-SIZE: 13.5pt">Dr. Khaled Ragab

kabdultawab@kfu.edu.sa

 

<= SPAN style=3D"COLOR: black; FONT-SIZE: 13.5pt">Dr. Azween B Abdullah= &nbs= p;            &= nbsp;           azweenabdullah@petronas.com.my

Frederic-Philippe Metz <frederic.m= etz@gmail.com>
=B7=A2=BC=FE=C8=CB:  p2psip-bounces@i= etf.org

2010-10-23 15:31

=CA=D5=BC=FE=C8= =CB
P2PSIP@ietf.org
=B3=AD=CB=CD
=D6=F7=CC=E2
[P2PSIP] Clarification of ini= tial attach procedure





Hi all,

I've got a question resp. page 123:

The first attach in the call flow diagram states JP as the
destination. I think it should be AP ? JP has got the node-id of AP
from a previous ping, right ? If that assumption is not right, the
attach to node-id JP will fail, because 5.5.1 states that the attach
to a node-id which isn't reached will fail.

Cheers,
Fr=A8=A6d=A8=A6ric
_______________________________________________
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.

--0015174c1d00709c8404936c0bbb-- From davidbryan@gmail.com Mon Oct 25 11:38:24 2010 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 BAB713A66B4 for ; Mon, 25 Oct 2010 11:38:24 -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=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Kh4jUreWrQeF for ; Mon, 25 Oct 2010 11:38:24 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id C02523A63D3 for ; Mon, 25 Oct 2010 11:38:23 -0700 (PDT) Received: by vws6 with SMTP id 6so374492vws.31 for ; Mon, 25 Oct 2010 11:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=jaw36Ucs4y4LkiJ8hgsaYB50jirkyILLgswhzVuVryg=; b=ekEDD3vfilJxuWrHXTekKUHjQrGk46+spP02oOJXXFEDKb9snazXI4i7rqTf6ccp2k Br+eFfKgiIi/ymfYZR6azJM4Kiv2bzD2BdrWgJzK6nsPQ9xlDuYKejm8F7T0C98eEUNo o1np2Hwbcpcr2Fc6xpmCEDM8gTMt4NIbSai+E= 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=bemHbvzwf7cayWwFjNbZvGq5BZg53sImdZFZav0nUjtcyZQmNy+akNaCQAJOLI/p0R 1FyoY0dreNRlmu0G/ZAkJHzo078qmQJ400XR05HoLLHf0DqvvLYzpG7TC+j1eNdb11Wg rYFO+gsG6PyBntGJWHvO93/wOch7zDIqXk/2A= MIME-Version: 1.0 Received: by 10.103.138.4 with SMTP id q4mr3450341mun.83.1288032008391; Mon, 25 Oct 2010 11:40:08 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.223.104.69 with HTTP; Mon, 25 Oct 2010 11:40:08 -0700 (PDT) In-Reply-To: <20101025183558.672C13A682F@core3.amsl.com> References: <20101025183558.672C13A682F@core3.amsl.com> Date: Mon, 25 Oct 2010 14:40:08 -0400 X-Google-Sender-Auth: peaspHApd8nQzoW3vWEPKsQblfU Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [P2PSIP] Fwd: New Version Notification for draft-ietf-p2psip-concepts-03 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, 25 Oct 2010 18:38:24 -0000 Several meetings ago, the WG indicated that once RELOAD settled down, they wanted the editors of the concepts draft to update it to reflect RELOAD and the decisions made. We have done that, and the new version is available. Please let us know if there are any issues, or more importantly, spots we failed to update or incorrectly captured the changes since RELOAD stabilized. Thanks, David (as individual) ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Oct 25, 2010 at 2:35 PM Subject: New Version Notification for draft-ietf-p2psip-concepts-03 To: bryan@ethernot.org Cc: philip_matthews@magma.ca, eunsooshim@gmail.com, dean.willis@softarmor.com, spencer@wonderhamster.org A new version of I-D, draft-ietf-p2psip-concepts-03.txt has been successfully submitted by David Bryan and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-ietf-p2psip-concepts Revision: =A0 =A0 =A0 =A003 Title: =A0 =A0 =A0 =A0 =A0 Concepts and Terminology for Peer to Peer SIP Creation_date: =A0 2010-10-25 WG ID: =A0 =A0 =A0 =A0 =A0 p2psip Number_of_pages: 20 Abstract: This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. =A0These mechansims may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. =A0This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group and the RELOAD protocol ([I-D.ietf-p2psip-base], [I-D.ietf-p2psip-sip]) defined by the working group. The IETF Secretariat. From root@core3.amsl.com Mon Oct 25 11:45:01 2010 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A9BE63A682F; Mon, 25 Oct 2010 11:45: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: <20101025184501.A9BE63A682F@core3.amsl.com> Date: Mon, 25 Oct 2010 11:45:01 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-concepts-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: Mon, 25 Oct 2010 18:45: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 : Concepts and Terminology for Peer to Peer SIP Author(s) : D. Bryan, et al. Filename : draft-ietf-p2psip-concepts-03.txt Pages : 20 Date : 2010-10-25 This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. These mechansims may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group and the RELOAD protocol ([I-D.ietf-p2psip-base], [I-D.ietf-p2psip-sip]) defined by the working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-concepts-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-concepts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25113558.I-D@ietf.org> --NextPart-- From peng.yonglin@zte.com.cn Mon Oct 25 18:58:11 2010 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 E1D9F3A67BE; Mon, 25 Oct 2010 18:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.786 X-Spam-Level: X-Spam-Status: No, score=-95.786 tagged_above=-999 required=5 tests=[AWL=1.207, 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 ydNLA2gGma6v; Mon, 25 Oct 2010 18:58:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id EC56E3A677D; Mon, 25 Oct 2010 18:58:09 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35103559614510; Tue, 26 Oct 2010 09:58:32 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 55813.5680175289; Tue, 26 Oct 2010 09:59:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o9Q1uYGu085226; Tue, 26 Oct 2010 09:56:37 +0800 (CST) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: To: Frederic-Philippe Metz MIME-Version: 1.0 X-KeepSent: C1D7E285:F8E759AD-482577C8:0008425D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.yonglin@zte.com.cn Date: Tue, 26 Oct 2010 09:56:23 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-26 09:56:30, Serialize complete at 2010-10-26 09:56:30 Content-Type: multipart/alternative; boundary="=_alternative 000AA29F482577C8_=" X-MAIL: mse2.zte.com.cn o9Q1uYGu085226 Cc: p2psip@ietf.org, p2psip-bounces@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6IAm08Li0OiAgQ2xhcmlmaWNhdGlvbiBv?= =?gb2312?b?ZiBpbml0aWFsIGF0dGFjaCBwcm9jZWR1cmU=?= 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, 26 Oct 2010 01:58:12 -0000 This is a multipart message in MIME format. --=_alternative 000AA29F482577C8_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 WWVzLCB0aGVzZSBtZXRob2RzIGFyZSBhbHNvIG9rLg0KSXQgYXBwZWFyIHRvIGJlIGluY29uc2lz dGVudCBiZXR3ZWVuIHNlY3Rpb24gOS41IGFuZCBzZWN0aW9uIDExLiAgSSB0aGluayANCnRoZSBt ZXRob2QgaW4gc2VjdGlvbiAxMSBpcyBtb3JlIGVmZmljaWVudC4NCg0KDQoNCg0KDQpGcmVkZXJp Yy1QaGlsaXBwZSBNZXR6IDxmcmVkZXJpYy5tZXR6QGdtYWlsLmNvbT4gDQrlj5Hku7bkuro6ICBw MnBzaXAtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0xMC0yNSAxNTozNg0KDQrmlLbku7bkuroNCnAy cHNpcEBpZXRmLm9yZw0K5oqE6YCBDQoNCuS4u+mimA0KUmU6IFtQMlBTSVBdICAgIOetlOWkjTog IENsYXJpZmljYXRpb24gb2YgaW5pdGlhbCBhdHRhY2ggcHJvY2VkdXJlDQoNCg0KDQoNCg0KDQpP ay4gU28gSlAgZWl0aGVyIGNhbg0KYSkgU2VuZCBhIHBpbmcgdG8gdGhlIHJlc291cmNlIGlkKzEg KGFzIHRoZSBub2RlX2lkIG9mIEpQKSB0byBnZXQgdGhlIA0Kbm9kZS1pZCAoaW4gdGhlIFJFTE9B RCBtZXNzYWdlIHNpZ25hdHVyZSBvZiB0aGUgUGluZyBhbnN3ZXIpIHRvIHRoZW4gDQpwZXJmb3Jt IGFuIGF0dGFjaCB0byB0aGlzIG5vZGVfaWQgKHRoaXMgaXMgbWVudGlvbmVkIGluIDkuNCkgb3IN CmIpIGRpcmVjdGx5IGZvcm0gYSByZXNvdXJjZS1pZCsxIChhcyBKUCdzIG5vZGVfaWQpIGFuZCBz ZW5kIGFuIGF0dGFjaC4NCg0KRG8geW91IGFncmVlID8gDQoNCkNoZWVycywNCiAgICBGcmVkZXJp Yw0KDQpPbiBNb24sIE9jdCAyNSwgMjAxMCBhdCA5OjA0IEFNLCA8cGVuZy55b25nbGluQHp0ZS5j b20uY24+IHdyb3RlOg0KDQpJIHRoaW5rIEpQIGlzIGNvcnJlY3QuIFRoZSBOb2RlIG9mIEpQIGlz IGFzIFJlc291cmNlLUlEIGluIEF0dGFjaC4gQmVmb3JlIA0KQXR0YWNoaW5nLCBhIFBpbmcgbWVz c2FnZSBpcyByZWR1bmRhbnQuIA0KDQpUaGVyZSBpcyB0aGUgZGVzY3JpcHRpb24gYWJvdmUgdGhl IHNlY29uZCBkaXJncmFtIGluIHRoZSBkcmFmdDogDQoiSXQgc2VuZHMgYW4gQXR0YWNoIHRvIHRo ZSBSZXNvdXJjZS1JUCBBUCsxLCB3aGljaCBnZXRzIHJvdXRlZCB0byBOUC4iIA0KDQoiUmVzb3Vy Y2UtSVAiIHNob3VsZCBiZSAiUmVzb3VyY2UtSUQiLiANCg0KDQoNCg0KRnJlZGVyaWMtUGhpbGlw cGUgTWV0eiA8ZnJlZGVyaWMubWV0ekBnbWFpbC5jb20+IA0K5Y+R5Lu25Lq6OiAgcDJwc2lwLWJv dW5jZXNAaWV0Zi5vcmcgDQoyMDEwLTEwLTIzIDE1OjMxIA0KDQoNCuaUtuS7tuS6ug0KUDJQU0lQ QGlldGYub3JnIA0K5oqE6YCBDQoNCuS4u+mimA0KW1AyUFNJUF0gQ2xhcmlmaWNhdGlvbiBvZiBp bml0aWFsIGF0dGFjaCBwcm9jZWR1cmUNCg0KDQoNCg0KDQoNCg0KDQpIaSBhbGwsDQoNCkkndmUg Z290IGEgcXVlc3Rpb24gcmVzcC4gcGFnZSAxMjM6DQoNClRoZSBmaXJzdCBhdHRhY2ggaW4gdGhl IGNhbGwgZmxvdyBkaWFncmFtIHN0YXRlcyBKUCBhcyB0aGUNCmRlc3RpbmF0aW9uLiBJIHRoaW5r IGl0IHNob3VsZCBiZSBBUCA/IEpQIGhhcyBnb3QgdGhlIG5vZGUtaWQgb2YgQVANCmZyb20gYSBw cmV2aW91cyBwaW5nLCByaWdodCA/IElmIHRoYXQgYXNzdW1wdGlvbiBpcyBub3QgcmlnaHQsIHRo ZQ0KYXR0YWNoIHRvIG5vZGUtaWQgSlAgd2lsbCBmYWlsLCBiZWNhdXNlIDUuNS4xIHN0YXRlcyB0 aGF0IHRoZSBhdHRhY2gNCnRvIGEgbm9kZS1pZCB3aGljaCBpc24ndCByZWFjaGVkIHdpbGwgZmFp bC4NCg0KQ2hlZXJzLA0KRnLDqWTDqXJpYw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClAyUFNJUCBtYWlsaW5nIGxpc3QNClAyUFNJUEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4gUmVjaXBpZW50 cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIA0KYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh dGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBt ZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGkt U3BhbSANCnN5c3RlbS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClAyUFNJUCBtYWlsaW5nIGxpc3QNClAyUFNJUEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg0KDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3Nl IG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 000AA29F482577C8_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcywgdGhlc2UgbWV0aG9kcyBh cmUgYWxzbyBvay48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0 IGFwcGVhciB0byBiZSBpbmNvbnNpc3RlbnQgYmV0d2Vlbg0Kc2VjdGlvbiA5LjUgYW5kIHNlY3Rp b24gMTEuICZuYnNwO0kgdGhpbmsgdGhlIG1ldGhvZCBpbiBzZWN0aW9uIDExIGlzIG1vcmUNCmVm ZmljaWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+RnJlZGVyaWMtUGhpbGlwcGUgTWV0eg0KJmx0O2ZyZWRlcmljLm1l dHpAZ21haWwuY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7lj5Hku7bkuro6ICZuYnNwO3AycHNpcC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMTAtMjUgMTU6MzY8L2ZvbnQ+ DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuaUtuS7 tuS6ujwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+cDJw c2lwQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mioTpgIE8L2ZvbnQ+PC9kaXY+DQo8 dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPuS4u+mimDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQMlBTSVBdICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O+etlOWkjToNCiZuYnNwO0NsYXJpZmljYXRpb24gb2YgaW5pdGlhbCBhdHRhY2ggcHJvY2VkdXJl PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPk9rLiBTbyBKUCBlaXRoZXIgY2FuPGJyPg0KYSkgU2VuZCBhIHBpbmcg dG8gdGhlIHJlc291cmNlIGlkKzEgKGFzIHRoZSBub2RlX2lkIG9mIEpQKSB0byBnZXQgdGhlIG5v ZGUtaWQNCihpbiB0aGUgUkVMT0FEIG1lc3NhZ2Ugc2lnbmF0dXJlIG9mIHRoZSBQaW5nIGFuc3dl cikgdG8gdGhlbiBwZXJmb3JtIGFuDQphdHRhY2ggdG8gdGhpcyBub2RlX2lkICh0aGlzIGlzIG1l bnRpb25lZCBpbiA5LjQpIG9yPGJyPg0KYikgZGlyZWN0bHkgZm9ybSBhIHJlc291cmNlLWlkKzEg KGFzIEpQJ3Mgbm9kZV9pZCkgYW5kIHNlbmQgYW4gYXR0YWNoLjxicj4NCjxicj4NCkRvIHlvdSBh Z3JlZSA/IDxicj4NCjxicj4NCkNoZWVycyw8YnI+DQogJm5ic3A7ICZuYnNwO0ZyZWRlcmljPGJy Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5PbiBNb24sIE9j dCAyNSwgMjAxMCBhdCA5OjA0IEFNLCAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnBlbmcueW9u Z2xpbkB6dGUuY29tLmNuPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pjx1PnBlbmcueW9uZ2xpbkB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZndDsNCndyb3RlOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KSSB0aGluayBKUCBpcyBjb3JyZWN0LiBUaGUgTm9kZSBvZiBK UCBpcyBhcyBSZXNvdXJjZS1JRCBpbiBBdHRhY2guIEJlZm9yZQ0KQXR0YWNoaW5nLCBhIFBpbmcg bWVzc2FnZSBpcyByZWR1bmRhbnQuIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGVy ZSBpcyB0aGUgZGVzY3JpcHRpb24gYWJvdmUgdGhlIHNlY29uZCBkaXJncmFtIGluIHRoZSBkcmFm dDogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJnF1b3Q7SXQg c2VuZHMgYW4gQXR0YWNoIHRvIHRoZSA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNl PSJDb3VyaWVyIE5ldyI+PGI+UmVzb3VyY2UtSVA8L2I+PC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+DQpBUCsxLCB3aGljaCBnZXRzIHJvdXRlZCB0byBOUC4mcXVvdDs8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQomcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij5SZXNvdXJjZS1JUDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+JnF1b3Q7DQpzaG91bGQgYmUgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+JnF1b3Q7UmVzb3VyY2UtSUQmcXVvdDsuPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDklPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5GcmVkZXJpYy1QaGlsaXBwZSBNZXR6DQombHQ7PC9iPjwvZm9u dD48YSBocmVmPW1haWx0bzpmcmVkZXJpYy5tZXR6QGdtYWlsLmNvbSB0YXJnZXQ9X2JsYW5rPjxm b250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PmZyZWRlcmljLm1l dHpAZ21haWwuY29tPC91PjwvYj48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj48Yj4mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7lj5Hku7bkuro6ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86cDJwc2lwLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+PHU+cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxMC0xMC0yMyAxNTozMTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NTAlPg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0xMCU+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+DQo8 dGQgd2lkdGg9ODklPjxhIGhyZWY9bWFpbHRvOlAyUFNJUEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5r Pjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PlAyUFNJUEBpZXRm Lm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+5oqE6YCBPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7kuLvpopg8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PltQMlBTSVBdIENsYXJpZmljYXRpb24gb2YgaW5pdGlhbCBhdHRhY2gNCnByb2NlZHVyZTwvZm9u dD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+SGkgYWxsLDxicj4NCjxicj4NCkkndmUgZ290IGEgcXVlc3Rp b24gcmVzcC4gcGFnZSAxMjM6PGJyPg0KPGJyPg0KVGhlIGZpcnN0IGF0dGFjaCBpbiB0aGUgY2Fs bCBmbG93IGRpYWdyYW0gc3RhdGVzIEpQIGFzIHRoZTxicj4NCmRlc3RpbmF0aW9uLiBJIHRoaW5r IGl0IHNob3VsZCBiZSBBUCA/IEpQIGhhcyBnb3QgdGhlIG5vZGUtaWQgb2YgQVA8YnI+DQpmcm9t IGEgcHJldmlvdXMgcGluZywgcmlnaHQgPyBJZiB0aGF0IGFzc3VtcHRpb24gaXMgbm90IHJpZ2h0 LCB0aGU8YnI+DQphdHRhY2ggdG8gbm9kZS1pZCBKUCB3aWxsIGZhaWwsIGJlY2F1c2UgNS41LjEg c3RhdGVzIHRoYXQgdGhlIGF0dGFjaDxicj4NCnRvIGEgbm9kZS1pZCB3aGljaCBpc24ndCByZWFj aGVkIHdpbGwgZmFpbC48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KRnLDqWTDqXJpYzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpQMlBTSVAgbWFpbGluZyBsaXN0PC9mb250PjwvdHQ+PHR0 Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PC90dD48YSBocmVm PW1haWx0bzpQMlBTSVBAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48dHQ+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWU+PHU+UDJQU0lQQGlldGYub3JnPC91PjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAgdGFyZ2V0PV9ibGFuaz48dHQ+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wMnBzaXA8L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0K PC9mb250PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwv Zm9udD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0zPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCmlzIHNvbGVs eSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVu aWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxp Z2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Ns b3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQpU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZg0KdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxicj4NCjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpQMlBTSVAgbWFpbGluZyBsaXN0PGJyPg0KUDJQ U0lQQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w MnBzaXA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9y bWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRp b24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJz cDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJz cDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7 YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7 c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3Rv Jm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZu YnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZu YnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5i c3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZu YnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7 dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUm bmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJz cDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2Um bmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJz cDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0 ZW0uDQo8L3ByZT4= --=_alternative 000AA29F482577C8_=-- From michaelc@idssoftware.com Mon Oct 25 21:06:41 2010 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 93CEC3A67E2 for ; Mon, 25 Oct 2010 21:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 OfgWyjgAjraZ for ; Mon, 25 Oct 2010 21:06:37 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id C9FF03A67B1 for ; Mon, 25 Oct 2010 21:06:36 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PAapi-00052w-Br for p2psip@ietf.org; Tue, 26 Oct 2010 00:08:22 -0400 Message-ID: <4CC662A2.60907@idssoftware.com> Date: Mon, 25 Oct 2010 21:09:54 -0800 From: Michael Chen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: p2psip@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070504070305080009000509" X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940aca72eb523ba4cfb1a09884e1527f72c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Subject: Re: [P2PSIP] =?utf-8?b?562U5aSNOiAgQ2xhcmlmaWNhdGlvbiBvZiBpbml0aWFs?= =?utf-8?q?_attach_procedure?= 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, 26 Oct 2010 04:06:41 -0000 This is a multi-part message in MIME format. --------------070504070305080009000509 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit My implementation agrees with Mr. Peng. There is no need for JP to use Ping to find AP. Just send an Attach with a *Resource-ID* as destination which contains _JP's own ID_ to the bootstrap node. Since this is a *Resource-ID*, it will be routed to the responsible node, which is AP. AP's reply will be routed back to JP to start the ICE check. Did I mention it's a *Resource-ID*? :) It is the key to this join method. Thanks --Michael On 10/24/2010 11:04 PM, peng.yonglin@zte.com.cn wrote: > > I think JP is correct. The Node of JP is as Resource-ID in Attach. Before > Attaching, a Ping message is redundant. > > There is the description above the second dirgram in the draft: > "It sends an Attach to the *Resource-IP* AP+1, which gets routed to NP." > > "Resource-IP" should be "Resource-ID". > > > > > *Frederic-Philippe Metz * > 发件人: p2psip-bounces@ietf.org > > 2010-10-23 15:31 > > > 收件人 > P2PSIP@ietf.org > 抄送 > > 主题 > [P2PSIP] Clarification of initial attach procedure > > > > > > > > > > Hi all, > > I've got a question resp. page 123: > > The first attach in the call flow diagram states JP as the > destination. I think it should be AP ? JP has got the node-id of AP > from a previous ping, right ? If that assumption is not right, the > attach to node-id JP will fail, because 5.5.1 states that the attach > to a node-id which isn't reached will fail. > > Cheers, > Frédéric > _______________________________________________ > 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. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --------------070504070305080009000509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
My implementation agrees with Mr. Peng. There is no need for JP to use Ping to find AP. Just send an Attach with a Resource-ID as destination which contains JP's own ID to the bootstrap node.  Since this is a Resource-ID, it will be routed to the responsible node, which is AP. AP's reply will be routed back to JP to start the ICE check.

Did I mention it's a Resource-ID? :) It is the key to this join method.

Thanks

--Michael

On 10/24/2010 11:04 PM, peng.yonglin@zte.com.cn wrote:

I think JP is correct. The Node of JP is as Resource-ID in Attach. Before Attaching, a Ping message is redundant.

There is the description above the second dirgram in the draft:
"It sends an Attach to the Resource-IP AP+1, which gets routed to NP."

"Resource-IP" should be "Resource-ID".




Frederic-Philippe Metz <frederic.metz@gmail.com>
发件人:  p2psip-bounces@ietf.org

2010-10-23 15:31

收件人
 P2PSIP@ietf.org
抄送
主题
 [P2PSIP] Clarification of initial attach procedure







Hi all,

I've got a question resp. page 123:

The first attach in the call flow diagram states JP as the
destination. I think it should be AP ? JP has got the node-id of AP
from a previous ping, right ? If that assumption is not right, the
attach to node-id JP will fail, because 5.5.1 states that the attach
to a node-id which isn't reached will fail.

Cheers,
Frédéric
_______________________________________________
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.


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
--------------070504070305080009000509-- From bbl@lowekamp.net Tue Oct 26 10:46:12 2010 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 1E8833A69D2; Tue, 26 Oct 2010 10:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=-1.526, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 OZVQj0vBNTBZ; Tue, 26 Oct 2010 10:46:10 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 50E2E3A69CC; Tue, 26 Oct 2010 10:46:10 -0700 (PDT) Received: by qwb7 with SMTP id 7so2861985qwb.31 for ; Tue, 26 Oct 2010 10:47:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.72 with SMTP id v8mr7610513qcl.215.1288115276665; Tue, 26 Oct 2010 10:47:56 -0700 (PDT) Received: by 10.229.12.198 with HTTP; Tue, 26 Oct 2010 10:47:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Oct 2010 10:47:56 -0700 Message-ID: From: Bruce Lowekamp To: peng.yonglin@zte.com.cn Content-Type: multipart/alternative; boundary=0016367f99f87ed2b2049388b505 Cc: Frederic-Philippe Metz , p2psip@ietf.org, p2psip-bounces@ietf.org Subject: Re: [P2PSIP] =?utf-8?b?562U5aSNOiBSZTog562U5aSNOiBDbGFyaWZpY2F0aW9u?= =?utf-8?q?_of_initial_attach_procedure?= 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, 26 Oct 2010 17:46:12 -0000 --0016367f99f87ed2b2049388b505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, using PING first introduces some corner failure cases that simply routing the ATTACH to the resource-id of JP does not. Section 9.5 doesn't actually conflict with the notion that the initial attach is routed to the JP's resource-id, though. 9.5 simply says that if peer A learns of peer B through peer C, it needs to send the ATTACH through peer C. This is simply because A may not have connectivity with B other than through peer C, such as when an overlay has been partitioned and is no= w healing. The initial ATTACH is essentially handled the same way, because i= t is routed via the BP. Bruce On Mon, Oct 25, 2010 at 6:56 PM, wrote: > > Yes, these methods are also ok. > It appear to be inconsistent between section 9.5 and section 11. I think > the method in section 11 is more efficient. > > > > > *Frederic-Philippe Metz * > =E5=8F=91=E4=BB=B6=E4=BA=BA: p2psip-bounces@ietf.org > > 2010-10-25 15:36 > =E6=94=B6=E4=BB=B6=E4=BA=BA > p2psip@ietf.org > =E6=8A=84=E9=80=81 > =E4=B8=BB=E9=A2=98 > Re: [P2PSIP] =E7=AD=94=E5=A4=8D: Clarification of initial attach = procedure > > > > > Ok. So JP either can > a) Send a ping to the resource id+1 (as the node_id of JP) to get the > node-id (in the RELOAD message signature of the Ping answer) to then perf= orm > an attach to this node_id (this is mentioned in 9.4) or > b) directly form a resource-id+1 (as JP's node_id) and send an attach. > > Do you agree ? > > Cheers, > Frederic > > On Mon, Oct 25, 2010 at 9:04 AM, <*peng.yonglin@zte.com.cn*> > wrote: > > I think JP is correct. The Node of JP is as Resource-ID in Attach. Before > Attaching, a Ping message is redundant. > > There is the description above the second dirgram in the draft: > "It sends an Attach to the *Resource-IP* AP+1, which gets routed to NP." > > "Resource-IP" should be "Resource-ID". > > > > *Frederic-Philippe Metz <**frederic.metz@gmail.com* > *>* > =E5=8F=91=E4=BB=B6=E4=BA=BA: *p2psip-bounces@ietf.org* > > 2010-10-23 15:31 > > =E6=94=B6=E4=BB=B6=E4=BA=BA > *P2PSIP@ietf.org* > =E6=8A=84=E9=80=81 > =E4=B8=BB=E9=A2=98 > [P2PSIP] Clarification of initial attach procedure > > > > > > > Hi all, > > I've got a question resp. page 123: > > The first attach in the call flow diagram states JP as the > destination. I think it should be AP ? JP has got the node-id of AP > from a previous ping, right ? If that assumption is not right, the > attach to node-id JP will fail, because 5.5.1 states that the attach > to a node-id which isn't reached will fail. > > Cheers, > Fr=C3=A9d=C3=A9ric > _______________________________________________ > 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 an= d > are not permitted to disclose the contents of this communication to other= s. > 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 individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > _______________________________________________ > 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. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > --0016367f99f87ed2b2049388b505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, using PING first introduces some corner failure cases that simply rout= ing the ATTACH to the resource-id of JP does not.

Section 9.5=C2=A0 doesn't actually conflict with the notion that the initial a= ttach=20 is routed to the JP's resource-id, though. =C2=A09.5 simply says that i= f peer A learns of peer B through peer C, it needs to send the ATTACH through=20 peer C.=C2=A0 This is simply because A may not have connectivity with B oth= er than through peer C, such as when an overlay has been partitioned and=20 is now healing.=C2=A0 The initial ATTACH is essentially handled the same wa= y, because it is routed via the BP.

Bruce


--0016367f99f87ed2b2049388b505-- From julian@orchidseed.org Tue Oct 26 15:13:59 2010 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 0D7EA3A68D2 for ; Tue, 26 Oct 2010 15:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.135 X-Spam-Level: X-Spam-Status: No, score=-1.135 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_SUB_ENC_UTF8=0.152] 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 uGsBVCoGmiPQ for ; Tue, 26 Oct 2010 15:13:56 -0700 (PDT) Received: from n25.c05.mtsvc.net (n25.c05.mtsvc.net [70.32.68.25]) by core3.amsl.com (Postfix) with ESMTP id C6BEE3A680B for ; Tue, 26 Oct 2010 15:13:56 -0700 (PDT) Received: from 71-22-238-54.gar.clearwire-wmx.net ([71.22.238.54]:35317 helo=[10.0.1.236]) by n25.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1PArns-00018m-QB; Tue, 26 Oct 2010 15:15:39 -0700 References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1-586455638 Message-Id: <5FD2B00E-A1A4-4F85-8AE6-8F65473F2B9A@orchidseed.org> X-Mailer: iPhone Mail (8B117) From: jc Date: Tue, 26 Oct 2010 18:14:55 -0400 To: Bruce Lowekamp X-Authenticated-User: 72798 julian@orchidseed.org Cc: Frederic-Philippe Metz , "p2psip@ietf.org" , "p2psip-bounces@ietf.org" Subject: Re: [P2PSIP] =?utf-8?b?562U5aSNOiBSZTog562U5aSNOiBDbGFyaWZpY2F0aW9u?= =?utf-8?q?_of_initial_attach_procedure?= 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, 26 Oct 2010 22:13:59 -0000 --Apple-Mail-1-586455638 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 26, 2010, at 1:47 PM, Bruce Lowekamp wrote: > Yes, using PING first introduces some corner failure cases that simply rou= ting the ATTACH to the resource-id of JP does not. >=20 > Section 9.5 doesn't actually conflict with the notion that the initial at= tach is routed to the JP's resource-id, though. =20 > 9.5 simply says that if peer A learns of peer B through peer C, it needs t= o send the ATTACH through peer C.=20 This is a MUST or should be IMO. > This is simply because A may not have connectivity with B other than throu= gh peer C, such as when an overlay has been partitioned and is now healing. = The initial ATTACH is essentially handled the same way, because it is route= d via the BP. >=20 > Bruce >=20 > On Mon, Oct 25, 2010 at 6:56 PM, wrote: >=20 > Yes, these methods are also ok.=20 > It appear to be inconsistent between section 9.5 and section 11. I think t= he method in section 11 is more efficient.=20 >=20 >=20 >=20 >=20 > Frederic-Philippe Metz =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: p2psip-bounces@ietf.org > 2010-10-25 15:36 >=20 > =E6=94=B6=E4=BB=B6=E4=BA=BA > p2psip@ietf.org > =E6=8A=84=E9=80=81 > =E4=B8=BB=E9=A2=98 > Re: [P2PSIP] =E7=AD=94=E5=A4=8D: Clarification of initial attach p= rocedure >=20 >=20 >=20 >=20 >=20 > Ok. So JP either can > a) Send a ping to the resource id+1 (as the node_id of JP) to get the node= -id (in the RELOAD message signature of the Ping answer) to then perform an a= ttach to this node_id (this is mentioned in 9.4) or > b) directly form a resource-id+1 (as JP's node_id) and send an attach. >=20 > Do you agree ?=20 >=20 > Cheers, > Frederic >=20 > On Mon, Oct 25, 2010 at 9:04 AM, wrote:=20 >=20 > I think JP is correct. The Node of JP is as Resource-ID in Attach. Before A= ttaching, a Ping message is redundant.=20 >=20 > There is the description above the second dirgram in the draft:=20 > "It sends an Attach to the Resource-IP AP+1, which gets routed to NP."=20 >=20 > "Resource-IP" should be "Resource-ID".=20 >=20 >=20 >=20 > Frederic-Philippe Metz =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: p2psip-bounces@ietf.org > 2010-10-23 15:31 >=20 >=20 > =E6=94=B6=E4=BB=B6=E4=BA=BA > P2PSIP@ietf.org > =E6=8A=84=E9=80=81 > =E4=B8=BB=E9=A2=98 > [P2PSIP] Clarification of initial attach procedure >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hi all, >=20 > I've got a question resp. page 123: >=20 > The first attach in the call flow diagram states JP as the > destination. I think it should be AP ? JP has got the node-id of AP > from a previous ping, right ? If that assumption is not right, the > attach to node-id JP will fail, because 5.5.1 states that the attach > to a node-id which isn't reached will fail. >=20 > Cheers, > Fr=C3=A9d=C3=A9ric=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is= solely property of the sender's organization. This mail communication is co= nfidential. 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. I= f you have received this email in error please notify the originator of the m= essage. Any views expressed in this message are those of the individual send= er. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system= . >=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 co= nfidential. 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. I= f you have received this email in error please notify the originator of the m= essage. Any views expressed in this message are those of the individual send= er. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system= . >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1-586455638 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8

On Oct 26, 2010, at 1:47 PM, Bruce Lowekamp <bbl@lowekamp.net> wrote:

Yes, using PING first introduces some corner failure cases that simply routing the ATTACH to the resource-id of JP does not.

Section 9.5  doesn't actually conflict with the notion that the initial attach is routed to the JP's resource-id, though.  

9.5 simply says that if peer A learns of peer B through peer C, it needs to send the ATTACH through peer C. 

This is a MUST or should be IMO.

This is simply because A may not have connectivity with B other than through peer C, such as when an overlay has been partitioned and is now healing.  The initial ATTACH is essentially handled the same way, because it is routed via the BP.

Bruce

On Mon, Oct 25, 2010 at 6:56 PM, <peng.yonglin@zte.com.cn> wrote:

Yes, these methods are also ok.
It appear to be inconsistent between section 9.5 and section 11.  I think the method in section 11 is more efficient.




Frederic-Philippe Metz <frederic.metz@gmail.com>
发件人:  p2psip-bounces@ietf.org

2010-10-25 15:36

收件人
p2psip@ietf.org
抄送
主题
Re: [P2PSIP]        答复:  Clarification of initial attach procedure





Ok. So JP either can
a) Send a ping to the resource id+1 (as the node_id of JP) to get the node-id (in the RELOAD message signature of the Ping answer) to then perform an attach to this node_id (this is mentioned in 9.4) or
b) directly form a resource-id+1 (as JP's node_id) and send an attach.

Do you agree ?

Cheers,
   Frederic
On Mon, Oct 25, 2010 at 9:04 AM, <peng.yonglin@zte.com.cn> wrote:

I think JP is correct. The Node of JP is as Resource-ID in Attach. Before Attaching, a Ping message is redundant.

There is the description above the second dirgram in the draft:
"It sends an Attach to the Resource-IP AP+1, which gets routed to NP."

"Resource-IP" should be "Resource-ID".



Frederic-Philippe Metz <frederic.metz@gmail.com>
发件人:  p2psip-bounces@ietf.org

2010-10-23 15:31


收件人
P2PSIP@ietf.org
抄送
主题
[P2PSIP] Clarification of initial attach procedure
Hi all,

I've got a question resp. page 123:

The first attach in the call flow diagram states JP as the
destination. I think it should be AP ? JP has got the node-id of AP
from a previous ping, right ? If that assumption is not right, the
attach to node-id JP will fail, because 5.5.1 states that the attach
to a node-id which isn't reached will fail.

Cheers,
Frédéric
_______________________________________________
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.
_______________________________________________
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.

_______________________________________________
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
--Apple-Mail-1-586455638-- From peng.yonglin@zte.com.cn Tue Oct 26 23:37:15 2010 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 CED2D3A68CE; Tue, 26 Oct 2010 23:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.612 X-Spam-Level: X-Spam-Status: No, score=-93.612 tagged_above=-999 required=5 tests=[AWL=-0.822, 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 uQbgSW7vDmFn; Tue, 26 Oct 2010 23:37: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 6AE6F3A67F6; Tue, 26 Oct 2010 23:37:12 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205953559614510; Wed, 27 Oct 2010 14:36:16 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.15] with StormMail ESMTP id 55813.6820879084; Wed, 27 Oct 2010 14:38:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id o9R6cBRS017752; Wed, 27 Oct 2010 14:38:11 +0800 (CST) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: To: Bruce Lowekamp MIME-Version: 1.0 X-KeepSent: 39E3BF64:905DA608-482577C9:00221B26; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.yonglin@zte.com.cn Date: Wed, 27 Oct 2010 14:37:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-10-27 14:38:00, Serialize complete at 2010-10-27 14:38:00 Content-Type: multipart/alternative; boundary="=_alternative 00246873482577C9_=" X-MAIL: mse3.zte.com.cn o9R6cBRS017752 Cc: Frederic-Philippe Metz , p2psip@ietf.org, p2psip-bounces@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiBSZTogtPC4tDogQ2xhcmlm?= =?gb2312?b?aWNhdGlvbiBvZiBpbml0aWFsIGF0dGFjaCBwcm9jZWR1cmU=?= 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, 27 Oct 2010 06:37:15 -0000 This is a multipart message in MIME format. --=_alternative 00246873482577C9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSdtIHNvcnJ5LCBpdCBpcyBlcnJvciBpbiBteSBsYXN0IGUtbWFpbC4gSXQgc2hvdWxkIGJlIHNl Y3Rpb24gOS40IHJhdGhlciANCnRoYW4gc2VjdGlvbiA5LjUgd2hpY2ggaXMgaW5jb25zaXN0ZW50 IHdpdGggc2VjdGlvbiAxMS4gDQoNCg0KDQoNCg0KDQpCcnVjZSBMb3dla2FtcCA8YmJsQGxvd2Vr YW1wLm5ldD4gDQoyMDEwLTEwLTI3IDAxOjQ3DQoNCsrVvP7Iyw0KcGVuZy55b25nbGluQHp0ZS5j b20uY24NCrOty80NCkZyZWRlcmljLVBoaWxpcHBlIE1ldHogPGZyZWRlcmljLm1ldHpAZ21haWwu Y29tPiwgcDJwc2lwQGlldGYub3JnLCANCnAycHNpcC1ib3VuY2VzQGlldGYub3JnDQrW98ziDQpS ZTogW1AyUFNJUF0gtPC4tDogUmU6ILTwuLQ6IENsYXJpZmljYXRpb24gb2YgaW5pdGlhbCBhdHRh Y2ggcHJvY2VkdXJlDQoNCg0KDQoNCg0KDQpZZXMsIHVzaW5nIFBJTkcgZmlyc3QgaW50cm9kdWNl cyBzb21lIGNvcm5lciBmYWlsdXJlIGNhc2VzIHRoYXQgc2ltcGx5IA0Kcm91dGluZyB0aGUgQVRU QUNIIHRvIHRoZSByZXNvdXJjZS1pZCBvZiBKUCBkb2VzIG5vdC4NCg0KU2VjdGlvbiA5LjUgIGRv ZXNuJ3QgYWN0dWFsbHkgY29uZmxpY3Qgd2l0aCB0aGUgbm90aW9uIHRoYXQgdGhlIGluaXRpYWwg DQphdHRhY2ggaXMgcm91dGVkIHRvIHRoZSBKUCdzIHJlc291cmNlLWlkLCB0aG91Z2guICA5LjUg c2ltcGx5IHNheXMgdGhhdCBpZiANCnBlZXIgQSBsZWFybnMgb2YgcGVlciBCIHRocm91Z2ggcGVl ciBDLCBpdCBuZWVkcyB0byBzZW5kIHRoZSBBVFRBQ0ggDQp0aHJvdWdoIHBlZXIgQy4gIFRoaXMg aXMgc2ltcGx5IGJlY2F1c2UgQSBtYXkgbm90IGhhdmUgY29ubmVjdGl2aXR5IHdpdGggQiANCm90 aGVyIHRoYW4gdGhyb3VnaCBwZWVyIEMsIHN1Y2ggYXMgd2hlbiBhbiBvdmVybGF5IGhhcyBiZWVu IHBhcnRpdGlvbmVkIA0KYW5kIGlzIG5vdyBoZWFsaW5nLiAgVGhlIGluaXRpYWwgQVRUQUNIIGlz IGVzc2VudGlhbGx5IGhhbmRsZWQgdGhlIHNhbWUgDQp3YXksIGJlY2F1c2UgaXQgaXMgcm91dGVk IHZpYSB0aGUgQlAuDQoNCkJydWNlDQoNCk9uIE1vbiwgT2N0IDI1LCAyMDEwIGF0IDY6NTYgUE0s IDxwZW5nLnlvbmdsaW5AenRlLmNvbS5jbj4gd3JvdGU6DQoNClllcywgdGhlc2UgbWV0aG9kcyBh cmUgYWxzbyBvay4gDQpJdCBhcHBlYXIgdG8gYmUgaW5jb25zaXN0ZW50IGJldHdlZW4gc2VjdGlv biA5LjUgYW5kIHNlY3Rpb24gMTEuICBJIHRoaW5rIA0KdGhlIG1ldGhvZCBpbiBzZWN0aW9uIDEx IGlzIG1vcmUgZWZmaWNpZW50LiANCg0KDQoNCg0KDQpGcmVkZXJpYy1QaGlsaXBwZSBNZXR6IDxm cmVkZXJpYy5tZXR6QGdtYWlsLmNvbT4gDQq3orz+yMs6ICBwMnBzaXAtYm91bmNlc0BpZXRmLm9y ZyANCjIwMTAtMTAtMjUgMTU6MzYgDQoNCg0KytW8/sjLDQpwMnBzaXBAaWV0Zi5vcmcgDQqzrcvN DQoNCtb3zOINClJlOiBbUDJQU0lQXSAgICAgICAgtPC4tDogIENsYXJpZmljYXRpb24gb2YgaW5p dGlhbCBhdHRhY2ggcHJvY2VkdXJlDQoNCg0KDQoNCg0KDQoNCg0KT2suIFNvIEpQIGVpdGhlciBj YW4NCmEpIFNlbmQgYSBwaW5nIHRvIHRoZSByZXNvdXJjZSBpZCsxIChhcyB0aGUgbm9kZV9pZCBv ZiBKUCkgdG8gZ2V0IHRoZSANCm5vZGUtaWQgKGluIHRoZSBSRUxPQUQgbWVzc2FnZSBzaWduYXR1 cmUgb2YgdGhlIFBpbmcgYW5zd2VyKSB0byB0aGVuIA0KcGVyZm9ybSBhbiBhdHRhY2ggdG8gdGhp cyBub2RlX2lkICh0aGlzIGlzIG1lbnRpb25lZCBpbiA5LjQpIG9yDQpiKSBkaXJlY3RseSBmb3Jt IGEgcmVzb3VyY2UtaWQrMSAoYXMgSlAncyBub2RlX2lkKSBhbmQgc2VuZCBhbiBhdHRhY2guDQoN CkRvIHlvdSBhZ3JlZSA/IA0KDQpDaGVlcnMsDQogICBGcmVkZXJpYw0KDQpPbiBNb24sIE9jdCAy NSwgMjAxMCBhdCA5OjA0IEFNLCA8cGVuZy55b25nbGluQHp0ZS5jb20uY24+IHdyb3RlOiANCg0K SSB0aGluayBKUCBpcyBjb3JyZWN0LiBUaGUgTm9kZSBvZiBKUCBpcyBhcyBSZXNvdXJjZS1JRCBp biBBdHRhY2guIEJlZm9yZSANCkF0dGFjaGluZywgYSBQaW5nIG1lc3NhZ2UgaXMgcmVkdW5kYW50 LiANCg0KVGhlcmUgaXMgdGhlIGRlc2NyaXB0aW9uIGFib3ZlIHRoZSBzZWNvbmQgZGlyZ3JhbSBp biB0aGUgZHJhZnQ6IA0KIkl0IHNlbmRzIGFuIEF0dGFjaCB0byB0aGUgUmVzb3VyY2UtSVAgQVAr MSwgd2hpY2ggZ2V0cyByb3V0ZWQgdG8gTlAuIiANCg0KIlJlc291cmNlLUlQIiBzaG91bGQgYmUg IlJlc291cmNlLUlEIi4gDQoNCg0KDQoNCkZyZWRlcmljLVBoaWxpcHBlIE1ldHogPGZyZWRlcmlj Lm1ldHpAZ21haWwuY29tPiANCreivP7IyzogIHAycHNpcC1ib3VuY2VzQGlldGYub3JnIA0KMjAx MC0xMC0yMyAxNTozMSANCg0KDQrK1bz+yMsNClAyUFNJUEBpZXRmLm9yZyANCrOty80NCg0K1vfM 4g0KW1AyUFNJUF0gQ2xhcmlmaWNhdGlvbiBvZiBpbml0aWFsIGF0dGFjaCBwcm9jZWR1cmUNCg0K DQoNCg0KDQoNCg0KDQoNCg0KSGkgYWxsLA0KDQpJJ3ZlIGdvdCBhIHF1ZXN0aW9uIHJlc3AuIHBh Z2UgMTIzOg0KDQpUaGUgZmlyc3QgYXR0YWNoIGluIHRoZSBjYWxsIGZsb3cgZGlhZ3JhbSBzdGF0 ZXMgSlAgYXMgdGhlDQpkZXN0aW5hdGlvbi4gSSB0aGluayBpdCBzaG91bGQgYmUgQVAgPyBKUCBo YXMgZ290IHRoZSBub2RlLWlkIG9mIEFQDQpmcm9tIGEgcHJldmlvdXMgcGluZywgcmlnaHQgPyBJ ZiB0aGF0IGFzc3VtcHRpb24gaXMgbm90IHJpZ2h0LCB0aGUNCmF0dGFjaCB0byBub2RlLWlkIEpQ IHdpbGwgZmFpbCwgYmVjYXVzZSA1LjUuMSBzdGF0ZXMgdGhhdCB0aGUgYXR0YWNoDQp0byBhIG5v ZGUtaWQgd2hpY2ggaXNuJ3QgcmVhY2hlZCB3aWxsIGZhaWwuDQoNCkNoZWVycywNCkZyqKZkqKZy aWMgDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUDJQ U0lQIG1haWxpbmcgbGlzdA0KUDJQU0lQQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5 IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5p Y2F0aW9uIGlzIA0KY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxp Z2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgDQphcmUgbm90IHBlcm1pdHRlZCB0byBkaXNj bG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCnRo ZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIA0KaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUDJQU0lQIG1haWxp bmcgbGlzdA0KUDJQU0lQQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3AycHNpcA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRz IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBh cmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHBy ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIu DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtIHN5c3RlbS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KUDJQU0lQIG1haWxpbmcgbGlzdA0KUDJQU0lQQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KDQoNCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5v dCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlv biB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4N Cg== --=_alternative 00246873482577C9_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknbSBzb3JyeSwgaXQgaXMgZXJy b3IgaW4gbXkgbGFzdCBlLW1haWwuDQpJdCBzaG91bGQgYmUgPC9mb250Pjxmb250IHNpemU9Mj5z ZWN0aW9uIDkuNDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yPnJhdGhlciB0aGFuIHNlY3Rpb24gOS41IHdoaWNoIDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aXMNCjwvZm9udD48Zm9udCBzaXplPTI+aW5jb25zaXN0 ZW50IHdpdGggc2VjdGlvbiAxMS4gPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0z NSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkJydWNlIExvd2VrYW1wICZsdDti YmxAbG93ZWthbXAubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4yMDEwLTEwLTI3IDAxOjQ3PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnBlbmcueW9uZ2xpbkB6dGUuY29tLmNuPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7mioTpgIE8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPkZyZWRlcmljLVBoaWxpcHBlIE1ldHogJmx0O2ZyZWRlcmljLm1l dHpAZ21haWwuY29tJmd0OywNCnAycHNpcEBpZXRmLm9yZywgcDJwc2lwLWJvdW5jZXNAaWV0Zi5v cmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuS4u+mimDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQMlBTSVBdIOetlOWkjTogUmU6IOetlOWkjTog Q2xhcmlmaWNhdGlvbg0Kb2YgaW5pdGlhbCBhdHRhY2ggcHJvY2VkdXJlPC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlllcywgdXNpbmcgUElORyBm aXJzdCBpbnRyb2R1Y2VzIHNvbWUgY29ybmVyIGZhaWx1cmUgY2FzZXMNCnRoYXQgc2ltcGx5IHJv dXRpbmcgdGhlIEFUVEFDSCB0byB0aGUgcmVzb3VyY2UtaWQgb2YgSlAgZG9lcyBub3QuPGJyPg0K PGJyPg0KU2VjdGlvbiA5LjUmbmJzcDsgZG9lc24ndCBhY3R1YWxseSBjb25mbGljdCB3aXRoIHRo ZSBub3Rpb24gdGhhdCB0aGUgaW5pdGlhbA0KYXR0YWNoIGlzIHJvdXRlZCB0byB0aGUgSlAncyBy ZXNvdXJjZS1pZCwgdGhvdWdoLiAmbmJzcDs5LjUgc2ltcGx5IHNheXMNCnRoYXQgaWYgcGVlciBB IGxlYXJucyBvZiBwZWVyIEIgdGhyb3VnaCBwZWVyIEMsIGl0IG5lZWRzIHRvIHNlbmQgdGhlIEFU VEFDSA0KdGhyb3VnaCBwZWVyIEMuJm5ic3A7IFRoaXMgaXMgc2ltcGx5IGJlY2F1c2UgQSBtYXkg bm90IGhhdmUgY29ubmVjdGl2aXR5DQp3aXRoIEIgb3RoZXIgdGhhbiB0aHJvdWdoIHBlZXIgQywg c3VjaCBhcyB3aGVuIGFuIG92ZXJsYXkgaGFzIGJlZW4gcGFydGl0aW9uZWQNCmFuZCBpcyBub3cg aGVhbGluZy4mbmJzcDsgVGhlIGluaXRpYWwgQVRUQUNIIGlzIGVzc2VudGlhbGx5IGhhbmRsZWQg dGhlDQpzYW1lIHdheSwgYmVjYXVzZSBpdCBpcyByb3V0ZWQgdmlhIHRoZSBCUC48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGNvbG9yPSM4ODg4ODg+PGJyPg0KPGJyPg0KQnJ1Y2U8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+T24gTW9uLCBPY3QgMjUsIDIwMTAg YXQgNjo1NiBQTSwgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpwZW5nLnlvbmdsaW5AenRlLmNv bS5jbj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5wZW5nLnlvbmdsaW5AenRlLmNvbS5jbjwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClllcywgdGhlc2UgbWV0aG9kcyBhcmUgYWxz byBvay48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCkl0IGFwcGVhciB0byBiZSBpbmNvbnNpc3RlbnQgYmV0d2VlbiBzZWN0aW9u IDkuNSBhbmQgc2VjdGlvbiAxMS4gJm5ic3A7SQ0KdGhpbmsgdGhlIG1ldGhvZCBpbiBzZWN0aW9u IDExIGlzIG1vcmUgZWZmaWNpZW50LjwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjxicj4NCjxi cj4NCjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD00MiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkZyZWRl cmljLVBoaWxpcHBlIE1ldHoNCiZsdDs8L2I+PC9mb250PjxhIGhyZWY9bWFpbHRvOmZyZWRlcmlj Lm1ldHpAZ21haWwuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+PHU+ZnJlZGVyaWMubWV0ekBnbWFpbC5jb208L3U+PC9iPjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZndDs8L2I+DQo8YnI+DQrl j5Hku7bkuro6ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86cDJwc2lwLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z ZXJpZiI+PHU+cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTM+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0xMC0y NSAxNTozNjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NTclPg0KPGJy Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD03JT4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuaUtuS7tuS6ujwv Zm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MiU+PGEgaHJlZj1tYWlsdG86cDJwc2lwQGlldGYub3Jn IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+ PHU+cDJwc2lwQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7mioTpgIE8L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuS4 u+mimDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6 IFtQMlBTSVBdICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO+etlOWkjToNCiZuYnNwO0NsYXJp ZmljYXRpb24gb2YgaW5pdGlhbCBhdHRhY2ggcHJvY2VkdXJlPC9mb250PjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUw JT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9 Mz48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Ck9rLiBTbyBKUCBlaXRoZXIgY2FuPGJyPg0KYSkgU2VuZCBhIHBpbmcgdG8gdGhlIHJlc291cmNl IGlkKzEgKGFzIHRoZSBub2RlX2lkIG9mIEpQKSB0byBnZXQgdGhlIG5vZGUtaWQNCihpbiB0aGUg UkVMT0FEIG1lc3NhZ2Ugc2lnbmF0dXJlIG9mIHRoZSBQaW5nIGFuc3dlcikgdG8gdGhlbiBwZXJm b3JtIGFuDQphdHRhY2ggdG8gdGhpcyBub2RlX2lkICh0aGlzIGlzIG1lbnRpb25lZCBpbiA5LjQp IG9yPGJyPg0KYikgZGlyZWN0bHkgZm9ybSBhIHJlc291cmNlLWlkKzEgKGFzIEpQJ3Mgbm9kZV9p ZCkgYW5kIHNlbmQgYW4gYXR0YWNoLjxicj4NCjxicj4NCkRvIHlvdSBhZ3JlZSA/IDxicj4NCjxi cj4NCkNoZWVycyw8YnI+DQombmJzcDsgJm5ic3A7RnJlZGVyaWM8L2ZvbnQ+PGZvbnQgc2l6ZT0z Pjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KT24gTW9u LCBPY3QgMjUsIDIwMTAgYXQgOTowNCBBTSwgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpwZW5n LnlvbmdsaW5AenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1PnBlbmcueW9uZ2xpbkB6dGUuY29tLmNuPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDsNCndyb3RlOjwvZm9udD48Zm9u dCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJy Pg0KSSB0aGluayBKUCBpcyBjb3JyZWN0LiBUaGUgTm9kZSBvZiBKUCBpcyBhcyBSZXNvdXJjZS1J RCBpbiBBdHRhY2guIEJlZm9yZQ0KQXR0YWNoaW5nLCBhIFBpbmcgbWVzc2FnZSBpcyByZWR1bmRh bnQuIDxicj4NCjxicj4NClRoZXJlIGlzIHRoZSBkZXNjcmlwdGlvbiBhYm92ZSB0aGUgc2Vjb25k IGRpcmdyYW0gaW4gdGhlIGRyYWZ0OiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48YnI+DQomcXVvdDtJdCBzZW5kcyBhbiBBdHRhY2ggdG8gdGhlIDwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9cmVkIGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj5SZXNvdXJjZS1JUDwvYj48L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCkFQKzEsIHdoaWNoIGdldHMgcm91 dGVkIHRvIE5QLiZxdW90OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCiZxdW90Ozwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlJlc291cmNlLUlQPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsNCnNob3VsZCBiZSA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mcXVvdDtSZXNvdXJjZS1JRCZxdW90Oy48L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9m b250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTQ5JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RnJlZGVyaWMtUGhpbGlwcGUg TWV0eg0KJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZnJlZGVyaWMubWV0ekBnbWFpbC5j b20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj48dT5mcmVkZXJpYy5tZXR6QGdtYWlsLmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjxicj4NCuWPkeS7tuS6ujogJm5i c3A7PC9mb250PjxhIGhyZWY9Im1haWx0bzpwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5wMnBz aXAtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEw LTEwLTIzIDE1OjMxPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD4NCjx0ZCB3aWR0aD01MCU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkIHdpZHRoPTEwJT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPuaUtuS7tuS6ujwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD04OSU+PGEgaHJl Zj1tYWlsdG86UDJQU0lQQGlldGYub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+UDJQU0lQQGlldGYub3JnPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7m ioTpgIE8L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuS4u+mimDwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1AyUFNJUF0gQ2xhcmlmaWNh dGlvbiBvZiBpbml0aWFsIGF0dGFjaA0KcHJvY2VkdXJlPC9mb250PjwvdGFibGU+DQo8YnI+PGZv bnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KSGkg YWxsLDxicj4NCjxicj4NCkkndmUgZ290IGEgcXVlc3Rpb24gcmVzcC4gcGFnZSAxMjM6PGJyPg0K PGJyPg0KVGhlIGZpcnN0IGF0dGFjaCBpbiB0aGUgY2FsbCBmbG93IGRpYWdyYW0gc3RhdGVzIEpQ IGFzIHRoZTxicj4NCmRlc3RpbmF0aW9uLiBJIHRoaW5rIGl0IHNob3VsZCBiZSBBUCA/IEpQIGhh cyBnb3QgdGhlIG5vZGUtaWQgb2YgQVA8YnI+DQpmcm9tIGEgcHJldmlvdXMgcGluZywgcmlnaHQg PyBJZiB0aGF0IGFzc3VtcHRpb24gaXMgbm90IHJpZ2h0LCB0aGU8YnI+DQphdHRhY2ggdG8gbm9k ZS1pZCBKUCB3aWxsIGZhaWwsIGJlY2F1c2UgNS41LjEgc3RhdGVzIHRoYXQgdGhlIGF0dGFjaDxi cj4NCnRvIGEgbm9kZS1pZCB3aGljaCBpc24ndCByZWFjaGVkIHdpbGwgZmFpbC48YnI+DQo8YnI+ DQpDaGVlcnMsPGJyPg0KRnLDqWTDqXJpYzwvZm9udD48L3R0Pjxmb250IHNpemU9Mz4gPC9mb250 Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpQMlBTSVAgbWFpbGluZyBsaXN0PC9mb250PjwvdHQ+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzpQMlBT SVBAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHU+ UDJQU0lQQGlldGYub3JnPC91PjwvZm9udD48L3R0PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZT48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wMnBzaXAgdGFyZ2V0PV9ibGFuaz48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWU+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8L3U+PC9m b250PjwvdHQ+PC9hPjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pjx0dD48 Zm9udCBzaXplPTM+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQpp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBt YWludGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdob20gdGhleSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUgbWVzc2FnZS4g QW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRp dmlkdWFsDQpzZW5kZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPC9mb250PjwvdHQ+PGZvbnQg c2l6ZT0zPjxicj4NCjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUDJQU0lQIG1haWxpbmcgbGlz dDwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9m b250PjwvdHQ+PGEgaHJlZj1tYWlsdG86UDJQU0lQQGlldGYub3JnIHRhcmdldD1fYmxhbms+PHR0 Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx1PlAyUFNJUEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC90 dD48L2E+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PC90 dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwIHRh cmdldD1fYmxhbms+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx1Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPC91PjwvZm9udD48L3R0PjwvYT48Zm9udCBz aXplPTM+PGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPjx0dD48Zm9udCBzaXplPTM+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpaVEUm bmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNw O2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZu YnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3Nl bmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVu aWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtu YW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWlu dGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0 ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZu YnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuPGJyPg0KVGhp cyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRl ZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZu YnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZu YnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7 eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4m bmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0 b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJz cDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7 dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuPGJyPg0K VGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2Zv ciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtB bnRpLVNwYW0mbmJzcDtzeXN0ZW0uPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0z Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KUDJQU0lQIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT48 YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOlAyUFNJUEBpZXRmLm9yZz48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZT48dT5QMlBTSVBAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZT48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNp cDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNl OiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0 aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZu YnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDtt YWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1Jl Y2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5i c3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtu b3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29u dGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtv dGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNw O3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFs Jm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJz cDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0 eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5i c3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1h aWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5i c3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJz cDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJz cDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3Nl bmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQm bmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRF Jm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00246873482577C9_=-- From davidbryan@gmail.com Wed Oct 27 17:24:00 2010 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 896A03A67B1 for ; Wed, 27 Oct 2010 17:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.77 X-Spam-Level: X-Spam-Status: No, score=-101.77 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pp+fAOvUoJHv for ; Wed, 27 Oct 2010 17:23:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4EF3A3A67AD for ; Wed, 27 Oct 2010 17:23:58 -0700 (PDT) Received: by wwe15 with SMTP id 15so1432830wwe.13 for ; Wed, 27 Oct 2010 17:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=g8Jk7M5ysufFu6sdvp/uka1N3nuNjYgFSsWqq10zOao=; b=oXjfciYMd1bVXQBpJI6PnbvxScyRRpy0xiOjSyI4lkOs8aiL9N6FCze/XTSkA/5u+2 sAyLUCanVvVKHH72m0FHSlrnG9mHrYDvoxwoiS6Fi8B4g0rzHcjRjaSf5EJV7b5cbxJt wDsbUcysjO2mWMqj2sYnYVMLAPdPVOPaiPRRA= 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; b=DVK3qilyAUZe8HluGjH/0ROploaEcbn4omw3ttMqBQBLRige5sJPfGnL+uTl/+YRiS iZpZjc0VGOGNLuLqN85qRp0omELezUOctFR8RFCUT8IThucCr/b26BIqYPdP03KFYLUD hplmOdqlajNVn2CEmWfb5dW706IIY1bQmUMws= MIME-Version: 1.0 Received: by 10.227.197.211 with SMTP id el19mr8186850wbb.62.1288225548864; Wed, 27 Oct 2010 17:25:48 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.227.207.195 with HTTP; Wed, 27 Oct 2010 17:25:48 -0700 (PDT) Date: Wed, 27 Oct 2010 20:25:48 -0400 X-Google-Sender-Auth: 3SU5YDyeOF5vKa2lygBvUMI6LYI Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] P2PSIP Draft Agenda Available 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, 28 Oct 2010 00:24:00 -0000 The draft agenda for P2PSIP is available here: http://www.ietf.org/proceedings/79/agenda/p2psip.html Remember that as with many other groups this time, to facilitate session participation by non-English speakers, please note the following policies: 1. If a presenter does not submit initial slides by end of day Friday (November 5) before the IETF meeting, the presentation slot will be removed from the agenda. 2. If a presenter does not provide final slides 24 hours before the WG session, we will use their initial slides. We are scheduled for 0900 Monday, so that deadline would be 0900 Sunday. Thanks, and see everyone in Beijing! David (as chair) From frederic.metz@gmail.com Thu Oct 28 00:04:27 2010 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 962E43A6842 for ; Thu, 28 Oct 2010 00:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.111 X-Spam-Level: ** X-Spam-Status: No, score=2.111 tagged_above=-999 required=5 tests=[AWL=-2.586, BAYES_00=-2.599, 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 KTzEU7Y8Unx6 for ; Thu, 28 Oct 2010 00:04:25 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B44703A6822 for ; Thu, 28 Oct 2010 00:04:24 -0700 (PDT) Received: by ewy27 with SMTP id 27so905023ewy.31 for ; Thu, 28 Oct 2010 00:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=sWXIKZM+RoP2TCpPgCkEQtUfOvEZ9eqbgMbjS9ylMvI=; b=mRGD6T1yXlHSZKGbnWyzNj2uEJ7y+ZS0zBn95UaB8KQwEs8MCGPoNwtLhgJlks2jLY iJEi+NdpAQZyrlVdatHtIb+0u6V3DfRIAit9yA2uj7CO2jJv4wieZ2CyoAwUeKapoGIy /qf+6a1Nm/cMAytyrJtcJVxYPIUw0iR0DeRNc= 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=YY75uBpp/6x8HGVLjr3Hg6zNtvKdM+Z/5/K0vO62YJqlmf4VJ1N6ddaqW955uWWzDQ lwJ2+WFh+wFkSWjAQSLUQNv9R2/IzO3cRLlHhcuv7JPsxqo2RKbJtLAOGVBqBnC58KY0 725X9Pmlx0jShQYXmaWkENJjATrjT2HQLW6mE= MIME-Version: 1.0 Received: by 10.213.10.136 with SMTP id p8mr8849543ebp.40.1288249575661; Thu, 28 Oct 2010 00:06:15 -0700 (PDT) Received: by 10.213.104.143 with HTTP; Thu, 28 Oct 2010 00:06:15 -0700 (PDT) In-Reply-To: <5FD2B00E-A1A4-4F85-8AE6-8F65473F2B9A@orchidseed.org> References: <5FD2B00E-A1A4-4F85-8AE6-8F65473F2B9A@orchidseed.org> Date: Thu, 28 Oct 2010 09:06:15 +0200 Message-ID: From: Frederic-Philippe Metz To: jc , Bruce Lowekamp Content-Type: multipart/alternative; boundary=0015174c136c56e48a0493a7fa65 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IENsYXJpZmljYXRpb24gb2Yg?= =?gb2312?b?aW5pdGlhbCBhdHRhY2ggcHJvY2VkdXJl?= 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, 28 Oct 2010 07:04:27 -0000 --0015174c136c56e48a0493a7fa65 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Thanks for clarifying that, it got it now. But there's one thing for me to understand which hasn't been discussed here= , yet: There were several sentences in the draft letting me understand that the connection table (if using not compressed destination_type) has the key as the node_id, where i.e. when the peer gets a message etc. and has an entry in the connection table for that peer, it must forward directly (without consulting the routing table). I understand this (hope this understanding i= s right here). But imagine the initial case: Assume you have a bootstrap up and running an= d no other node, and a new node want to enter the overlay, let say as a client: 1. The new node gets the config document, now it is becoming very interesting: 2. It does a TLS connection to that bootstrap node. What now in detail ? Now it has to insert the connection information paired with the bootstrap node_id in its connection table (and also Routing table) before routing any _first_ RELOAD Message to a node over that bootstrap. More precise: It has now a connection and has to insert the connection information with the node_id of the bootstrap peer into the connection table. Does it learn the node_id for that connection from any information out of TLS ? Cheers, Frederic On Wed, Oct 27, 2010 at 12:14 AM, jc wrote: > > On Oct 26, 2010, at 1:47 PM, Bruce Lowekamp wrote: > > Yes, using PING first introduces some corner failure cases that simply > routing the ATTACH to the resource-id of JP does not. > > Section 9.5 doesn't actually conflict with the notion that the initial > attach is routed to the JP's resource-id, though. > > > 9.5 simply says that if peer A learns of peer B through peer C, it needs = to > send the ATTACH through peer C. > > > This is a MUST or should be IMO. > > This is simply because A may not have connectivity with B other than > through peer C, such as when an overlay has been partitioned and is now > healing. The initial ATTACH is essentially handled the same way, because= it > is routed via the BP. > > Bruce > > On Mon, Oct 25, 2010 at 6:56 PM, < > peng.yonglin@zte.com.cn> wrote: > >> >> Yes, these methods are also ok. >> It appear to be inconsistent between section 9.5 and section 11. I thin= k >> the method in section 11 is more efficient. >> >> >> >> >> *Frederic-Philippe Metz < >> frederic.metz@gmail.com>* >> =B7=A2=BC=FE=C8=CB: p2psip-bounces@ietf.org >> >> 2010-10-25 15:36 >> =CA=D5=BC=FE=C8=CB >> p2psip@ietf.org >> =B3=AD=CB=CD >> =D6=F7=CC=E2 >> Re: [P2PSIP] =B4=F0=B8=B4: Clarification of initial attach proce= dure >> >> >> >> >> Ok. So JP either can >> a) Send a ping to the resource id+1 (as the node_id of JP) to get the >> node-id (in the RELOAD message signature of the Ping answer) to then per= form >> an attach to this node_id (this is mentioned in 9.4) or >> b) directly form a resource-id+1 (as JP's node_id) and send an attach. >> >> Do you agree ? >> >> Cheers, >> Frederic >> >> On Mon, Oct 25, 2010 at 9:04 AM, <*peng.yonglin@zte.com.cn*> >> wrote: >> >> I think JP is correct. The Node of JP is as Resource-ID in Attach. Befor= e >> Attaching, a Ping message is redundant. >> >> There is the description above the second dirgram in the draft: >> "It sends an Attach to the *Resource-IP* AP+1, which gets routed to NP." >> >> "Resource-IP" should be "Resource-ID". >> >> >> >> *Frederic-Philippe Metz <**frederic.metz@gmail.com* >> *>* >> =B7=A2=BC=FE=C8=CB: *p2psip-bounces@ietf.org* >> >> 2010-10-23 15:31 >> >> =CA=D5=BC=FE=C8=CB >> *P2PSIP@ietf.org* >> =B3=AD=CB=CD >> =D6=F7=CC=E2 >> [P2PSIP] Clarification of initial attach procedure >> >> >> >> >> >> >> Hi all, >> >> I've got a question resp. page 123: >> >> The first attach in the call flow diagram states JP as the >> destination. I think it should be AP ? JP has got the node-id of AP >> from a previous ping, right ? If that assumption is not right, the >> attach to node-id JP will fail, because 5.5.1 states that the attach >> to a node-id which isn't reached will fail. >> >> Cheers, >> Fr=A8=A6d=A8=A6ric >> _______________________________________________ >> 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 a= nd >> are not permitted to disclose the contents of this communication to othe= rs. >> 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 individual >> sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam >> system. >> >> _______________________________________________ >> 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 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 >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > --0015174c136c56e48a0493a7fa65 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Thanks for clarifying that, it got it now.

But there's one thing= for me to understand which hasn't been discussed here, yet:

The= re were several sentences in the draft letting me understand that the conne= ction table (if using not compressed destination_type) has the key as the n= ode_id, where i.e. when the peer gets a message etc. and has an entry in th= e connection table for that peer, it must forward directly (without consult= ing the routing table). I understand this (hope this understanding is right= here).

But imagine the initial case: Assume you have a bootstrap up and runnin= g and no other node, and a new node want to enter the overlay, let say as a= client:

1. The new node gets the config document, now it is becomin= g very interesting:
2. It does a TLS connection to that bootstrap node.

What now in deta= il ? Now it has to insert the connection information paired with the bootst= rap node_id in its connection table (and also Routing table) before routing= any _first_ RELOAD Message to a node over that bootstrap. More precise: It= has now a connection and has to insert the connection information with the= node_id of the bootstrap peer into the connection table. Does it learn the= node_id for that connection from any information out of TLS ?

Cheers,
Frederic


On Wed, Oct 2= 7, 2010 at 12:14 AM, jc <julian@orchidseed.org> wrote:

On Oct 26, 2= 010, at 1:47 PM, Bruce Lowekamp <bbl@lowekamp.net> wrote:

Yes, using PING first introduces some corner failure cases that simply= routing the ATTACH to the resource-id of JP does not.

Section 9.5  doesn't actually conflict with the notion that the initial a= ttach=20 is routed to the JP's resource-id, though.  
9.5 simply says that if peer A learns of peer B through peer C, it needs to send the ATTACH through=20 peer C. 

This is a MUST o= r should be IMO.

This is simply because A may not have connectivity with B o= ther than through peer C, such as when an overlay has been partitioned and=20 is now healing.  The initial ATTACH is essentially handled the same wa= y, because it is routed via the BP.

Bruce

On Mon, Oct 25, 2010 at = 6:56 PM, <peng.yonglin@zte.com.cn> wrote:

Yes, these methods are also ok.
It appear to be inconsistent betwe= en section 9.5 and section 11.  I think the method in section 11 is more efficient.




Frederic-Phi= lippe Metz <frederic.metz@gmail.= com>
=B7=A2=BC=FE=C8=CB:  p2psip-bounces@ietf.org

2010-10-25 15:36


=CA=D5=BC=FE=C8= =CB
p2psip@ietf.org
=B3=AD=CB=CD
=D6=F7=CC=E2
Re: [P2PSIP]     &n= bsp;  =B4=F0=B8=B4:  Clarification of initial attach procedure




Ok. So JP either can
a) Send a ping to the resource id+1 (as the node_id of JP) to get the node-= id (in the RELOAD message signature of the Ping answer) to then perform an attach to this node_id (this is mentioned in 9.4) or
b) directly form a resource-id+1 (as JP's node_id) and send an attach.<= br>
Do you agree ?

Cheers,
   Frederic
On Mon, Oct 25, 2010 at 9:04 AM, &= lt;peng.yonglin@zte.com.cn<= /u>> wrote:

I think JP is correct. The Node of JP is as Resource-ID in Attach. Before Attaching, a Ping message is redundant.

There is the description above the second dirgram in the draft:
"It sends an Attach to the Resource-IP AP+1, which gets routed to NP."

"Resource-IP" should be "Resource-ID&qu= ot;.



Frederic-Philippe= Metz <frederic.metz@gm= ail.com>
=B7=A2=BC=FE=C8=CB:  <= a href=3D"mailto:p2psip-bounces@ietf.org" target=3D"_blank">p2psip-bounces@ietf.org<= /a>

2010-10-23 15:31


=CA=D5=BC=FE=C8= =CB
P2PSIP@ietf.org=
=B3=AD=CB=CD
=D6=F7=CC=E2
[P2PSIP] Clarification of ini= tial attach procedure
Hi all,

I've got a question resp. page 123:

The first attach in the call flow diagram states JP as the
destination. I think it should be AP ? JP has got the node-id of AP
from a previous ping, right ? If that assumption is not right, the
attach to node-id JP will fail, because 5.5.1 states that the attach
to a node-id which isn't reached will fail.

Cheers,
Fr=A8=A6d=A8=A6ric
_______________________________________________ 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 communicatio= n 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 individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=

_______________________________________________ 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.

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip


___________________= ____________________________
P2PSIP mailing list
= P2PSIP@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/p2psip

--0015174c136c56e48a0493a7fa65-- From michaelc@IDSSOFTWARE.COM Thu Oct 28 12:13:40 2010 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 C00AD3A685B for ; Thu, 28 Oct 2010 12:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.479 X-Spam-Level: X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[AWL=0.632, 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 Q-bZAoZrR0jX for ; Thu, 28 Oct 2010 12:13:40 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by core3.amsl.com (Postfix) with SMTP id EA5B13A6833 for ; Thu, 28 Oct 2010 12:13:39 -0700 (PDT) Received: (qmail 20975 invoked from network); 28 Oct 2010 19:15:22 -0000 Received: from unknown (HELO gem-wbe26.prod.mesa1.secureserver.net) (64.202.189.160) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 28 Oct 2010 19:15:22 -0000 Received: (qmail 19870 invoked by uid 99); 28 Oct 2010 19:15:20 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 12.175.188.225 User-Agent: Web-Based Email 5.2.36 Message-Id: <20101028121520.61e8c06078a3b23a733c71e914c0b9df.8aa40a9313.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Thu, 28 Oct 2010 12:15:20 -0700 Mime-Version: 1.0 Subject: [P2PSIP] ICE nomination paragraph removed in base-11 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, 28 Oct 2010 19:13:40 -0000 Hi, I notice that in section 5.5.1.10.2, this paragraph was removed from the latest base-11 draft (diff with 10). Was there a discussion or reference on it? 5.5.1.10.2. Concluding ICE The controlling agent MUST utilize regular nomination. This is to =09 ensure consistent state on the final selected pairs without the need =09 for an updated offer, as RELOAD does not generate additional offer/ =09 answer exchanges. =09 Thanks --Michael
On Mon, Oct 25, 2010 at = 6:56 PM, <= peng.yonglin@zte.com.cn> wrote:

Yes, these methods are also ok.
It appear to be inconsistent betwe= en section 9.5 and section 11. =C2=A0I think the method in section 11 is more efficient.




Frederic-Philippe Metz <frederic.m= etz@gmail.com>
=E5=8F=91=E4=BB=B6=E4=BA=BA: =C2= =A0p2psip-boun= ces@ietf.org

2010-10-25 15:36


=E6=94=B6=E4=BB= =B6=E4=BA=BA
p2psip@ietf.org
=E6=8A=84=E9=80= =81
=E4=B8=BB=E9=A2= =98
Re: [P2PSIP] =C2=A0 =C2=A0 = =C2=A0 =C2=A0=E7=AD=94=E5=A4=8D: =C2=A0Clarification of initial attach procedure




Ok. So JP either can
a) Send a ping to the resource id+1 (as the node_id of JP) to get the node-= id (in the RELOAD message signature of the Ping answer) to then perform an attach to this node_id (this is mentioned in 9.4) or
b) directly form a resource-id+1 (as JP's node_id) and send an attach.<= br>
Do you agree ?

Cheers,
=C2=A0 =C2=A0Frederic
On Mon, Oct 25, 2010 at 9:04 AM, &= lt;peng.yonglin@zte.com.cn<= /u>> wrote:

I think JP is correct. The Node of JP is as Resource-ID in Attach. Before Attaching, a Ping message is redundant.

There is the description above the second dirgram in the draft:
"It sends an Attach to the Resource-IP AP+1, which gets routed to NP."

"Resource-IP" should be "Resource-ID&qu= ot;.



Frederic-Philippe= Metz <frederic.metz@gm= ail.com>
=E5=8F=91=E4=BB=B6=E4=BA=BA: =C2= =A0p2psip-bounces@ietf.org<= /u>

2010-10-23 15:31


=E6=94=B6=E4=BB= =B6=E4=BA=BA
P2PSIP@ietf.org=
=E6=8A=84=E9=80= =81
=E4=B8=BB=E9=A2= =98
[P2PSIP] Clarification of ini= tial attach procedure
Hi all,

I've got a question resp. page 123:

The first attach in the call flow diagram states JP as the
destination. I think it should be AP ? JP has got the node-id of AP
from a previous ping, right ? If that assumption is not right, the
attach to node-id JP will fail, because 5.5.1 states that the attach
to a node-id which isn't reached will fail.

Cheers,
Fr=C3=A9d=C3=A9ric
_______________________________________________ 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 communicatio= n 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 individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=

_______________________________________________ P2PSIP mailing list
P2PSIP@ietf.org = https://www.ietf.org/mailman/listinfo/p2psip
 

--------------------------------------------------------
ZTE=C2=A0Information=C2=A0Security=C2=A0Notice:=C2=A0The=C2=A0information=
=C2=A0contained=C2=A0in=C2=A0this=C2=A0mail=C2=A0is=C2=A0solely=C2=A0proper=
ty=C2=A0of=C2=A0the=C2=A0sender's=C2=A0organization.=C2=A0This=C2=A0mai=
l=C2=A0communication=C2=A0is=C2=A0confidential.=C2=A0Recipients=C2=A0named=
=C2=A0above=C2=A0are=C2=A0obligated=C2=A0to=C2=A0maintain=C2=A0secrecy=C2=
=A0and=C2=A0are=C2=A0not=C2=A0permitted=C2=A0to=C2=A0disclose=C2=A0the=C2=
=A0contents=C2=A0of=C2=A0this=C2=A0communication=C2=A0to=C2=A0others.
This=C2=A0email=C2=A0and=C2=A0any=C2=A0files=C2=A0transmitted=C2=A0with=C2=
=A0it=C2=A0are=C2=A0confidential=C2=A0and=C2=A0intended=C2=A0solely=C2=A0fo=
r=C2=A0the=C2=A0use=C2=A0of=C2=A0the=C2=A0individual=C2=A0or=C2=A0entity=C2=
=A0to=C2=A0whom=C2=A0they=C2=A0are=C2=A0addressed.=C2=A0If=C2=A0you=C2=A0ha=
ve=C2=A0received=C2=A0this=C2=A0email=C2=A0in=C2=A0error=C2=A0please=C2=A0n=
otify=C2=A0the=C2=A0originator=C2=A0of=C2=A0the=C2=A0message.=C2=A0Any=C2=
=A0views=C2=A0expressed=C2=A0in=C2=A0this=C2=A0message=C2=A0are=C2=A0those=
=C2=A0of=C2=A0the=C2=A0individual=C2=A0sender.
This=C2=A0message=C2=A0has=C2=A0been=C2=A0scanned=C2=A0for=C2=A0viruses=C2=
=A0and=C2=A0Spam=C2=A0by=C2=A0ZTE=C2=A0Anti-Spam=C2=A0system.

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip