From xianghan.zheng@uia.no Tue Jul 6 09:36: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 7FC243A63EC for ; Tue, 6 Jul 2010 09:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.755 X-Spam-Level: * X-Spam-Status: No, score=1.755 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 uFHjuKWZbzYZ for ; Tue, 6 Jul 2010 09:36:52 -0700 (PDT) Received: from pat.uia.no (pat.uia.no [158.36.80.144]) by core3.amsl.com (Postfix) with ESMTP id 7D2333A63C9 for ; Tue, 6 Jul 2010 09:36:52 -0700 (PDT) Received: from [158.36.80.150] (helo=mail-mx1.uia.no) by pat.uia.no with esmtp (Exim 4.69) (envelope-from ) id 1OWB8c-0000gZ-E0 for p2psip@ietf.org; Tue, 06 Jul 2010 18:36:50 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mail-mx1.uia.no) by mail-mx1.uia.no with esmtp (Exim 4.69) (envelope-from ) id 1OWB8c-0006ij-AL for p2psip@ietf.org; Tue, 06 Jul 2010 18:36:50 +0200 Received: from htkrs01.uia.no ([158.36.36.223]) by mail-mx1.uia.no with esmtp (Exim 4.69) (envelope-from ) id 1OWB8b-0006ia-Oa for p2psip@ietf.org; Tue, 06 Jul 2010 18:36:50 +0200 Received: from exchkrs01.uia.no ([fe80::e9bc:692e:658e:7f60]) by htkrs01.uia.no ([fe80::acd9:3dff:b867:3dc8%12]) with mapi; Tue, 6 Jul 2010 18:36:45 +0200 From: Xianghan Zheng To: "p2psip@ietf.org" Date: Tue, 6 Jul 2010 18:36:44 +0200 Thread-Topic: ID generation and P2P layer function questions Thread-Index: AQHLHSlrqcBvldVWiE+Xaq69zmE+aQ== Message-ID: Accept-Language: zh-CN, nb-NO Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, nb-NO Content-Type: multipart/alternative; boundary="_000_EDBBCE5904E6B14589AD6AB0B89CB4223C72F6616Eexchkrs01uian_" MIME-Version: 1.0 X-SA-Exim-Version: 4.2.1 (built Thu, 17 Jul 2008 09:48:05 +0200) Subject: [P2PSIP] ID generation and P2P layer function questions 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, 06 Jul 2010 16:36:53 -0000 --_000_EDBBCE5904E6B14589AD6AB0B89CB4223C72F6616Eexchkrs01uian_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIGdldCBxdWVzdGlvbnMgd2hlbiBpIHF1aWNrIHJldmlldyBSRUxPQUQgdjgg cHJvcG9zYWxzOg0KDQooMSkgUkVMT0FEIG1lbnRpb24gdGhhdCBjZW50cmFsIGVucm9sbG1lbnQg c2VydmVyIGlzIHVzZWQgZm9yIHRoZSBnZW5lcmF0aW9uIG9mIE5vZGUtSUQgKFNlY3Rpb24gMy41 LjIpLCBIb3dldmVyLCBpdCBsb29rcyBub3QgbWVudGlvbiBob3cgaXQgaXMgY2FsY3VsYXRlZC4g QnkgaGFzaGluZyB0aGUgU0lQIFVSST8gT3IgcmFuZG9tIGFzc2lnbm1lbnQ/DQoNCigyKSBDYW4g aSB1bmRlcnN0YW5kIFJFTE9BRCBwcm9wb3NhbCBpcyA5NSUgUDJQIGZ1bmN0aW9ucyBhbmQgd2l0 aCBhIGxpdHRsZSBiaXQgNSUgU0lQIHVzYWdlLCBzaW5jZSBtb3N0IG9mIHRoZSBmdW5jdGlvbnMg b3JpZ2luYWxseSBkZXNpZ25lZCBpbiBTSVAgcHJvdG9jb2wgaGF2ZSBiZWVuIG1pZ3JhdGVkIGlu dG8gUDJQIGxheWVyLg0KDQpSZWdhcmRzLA0KWGlhbmdoYW4NCg== --_000_EDBBCE5904E6B14589AD6AB0B89CB4223C72F6616Eexchkrs01uian_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi All,=

I get questions when= i quick review RELOAD v8 proposals:

(1) RELOAD mention that c= entral enrollment server is used for the generation of Node-ID (Section 3.5= .2), However, it looks not mention how it is calculated. By = hashing the SIP URI? Or random assignment?

(2) Can i understand RELOAD proposal= is 95% P2P functions and with a little bit 5% SIP usage, since most o= f the functions originally designed in SIP protocol have been mig= rated into P2P layer.

Regards,

Xianghan

--_000_EDBBCE5904E6B14589AD6AB0B89CB4223C72F6616Eexchkrs01uian_-- From ekr@rtfm.com Tue Jul 6 09:40: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 1BC1D3A69A4 for ; Tue, 6 Jul 2010 09:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF9QxP1oHmX3 for ; Tue, 6 Jul 2010 09:40: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 2D4B33A6878 for ; Tue, 6 Jul 2010 09:40:23 -0700 (PDT) Received: by gxk3 with SMTP id 3so1542831gxk.31 for ; Tue, 06 Jul 2010 09:40:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.28.19 with SMTP id b19mr4702070agb.101.1278434421223; Tue, 06 Jul 2010 09:40:21 -0700 (PDT) Received: by 10.90.34.8 with HTTP; Tue, 6 Jul 2010 09:40:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Jul 2010 19:40:21 +0300 Message-ID: From: Eric Rescorla To: Xianghan Zheng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] ID generation and P2P layer function questions 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, 06 Jul 2010 16:40:24 -0000 2010/7/6 Xianghan Zheng : > Hi All, > > I=A0get questions when i=A0quick review=A0RELOAD v8 proposals: > > (1) RELOAD mention that central enrollment server is used for the generat= ion > of Node-ID (Section 3.5.2), However,=A0it looks not mention=A0how it > is=A0calculated. By hashing the SIP URI? Or random assignment? " One or more Node-IDs which MUST be cryptographically random [RFC4086]. Each MUST be chosen by the enrollment server in such a way that they are unpredictable to the requesting user. Each is placed in the subjectAltName using the uniformResourceIdentifier type and MUST contain RELOAD URIs as described in Section 13.13 and MUST contain a Destination list with a single entry of type "node_id"." > (2)=A0Can i understand RELOAD proposal is 95% P2P functions and with a li= ttle > bit 5% SIP usage,=A0since most of the functions originally designed=A0in = SIP > protocol=A0have been migrated into P2P layer. I don't really know what that means. RELOAD is about arranging for a channel to teh peer over which SIP can then flow. It doesn't seem to me that that subsumes most of SIP but YMMV. -Ekr From andy@bluewire.net.nz Tue Jul 6 18:45:33 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 88D4E3A67F3 for ; Tue, 6 Jul 2010 18:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 wTdfe+Z-QALL for ; Tue, 6 Jul 2010 18:45:32 -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 4F6353A67F2 for ; Tue, 6 Jul 2010 18:45:32 -0700 (PDT) Received: by gxk3 with SMTP id 3so1818016gxk.31 for ; Tue, 06 Jul 2010 18:45:32 -0700 (PDT) Received: by 10.229.251.206 with SMTP id mt14mr3335371qcb.161.1278467131138; Tue, 06 Jul 2010 18:45:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.216.17 with HTTP; Tue, 6 Jul 2010 18:45:11 -0700 (PDT) In-Reply-To: References:

From: Andy Savage Date: Wed, 7 Jul 2010 09:45:11 +0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=0016364eccbe35634e048ac253a6 Cc: Xianghan Zheng , "p2psip@ietf.org" Subject: Re: [P2PSIP] ID generation and P2P layer function questions 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, 07 Jul 2010 01:45:33 -0000 --0016364eccbe35634e048ac253a6 Content-Type: text/plain; charset=ISO-8859-1 Where can I find more information on the RELOAD proposal? Sorry for my ignorance but is this the main proposed way for P2P SIP or is it part of many proposals? I'm a bit lost as to where things are at (although I joined the list to learn a bit more). I've found lots of historical information on the P2P SIP idea but just not sure where it's at now (July 2010). On Wed, Jul 7, 2010 at 12:40 AM, Eric Rescorla wrote: > 2010/7/6 Xianghan Zheng : > > Hi All, > > > > I get questions when i quick review RELOAD v8 proposals: > > > > (1) RELOAD mention that central enrollment server is used for the > generation > > of Node-ID (Section 3.5.2), However, it looks not mention how it > > is calculated. By hashing the SIP URI? Or random assignment? > > > " One or more Node-IDs which MUST be cryptographically random > [RFC4086]. Each MUST be chosen by the enrollment server in such a > way that they are unpredictable to the requesting user. Each is > placed in the subjectAltName using the uniformResourceIdentifier > type and MUST contain RELOAD URIs as described in Section 13.13 > and MUST contain a Destination list with a single entry of type > "node_id"." > > > > (2) Can i understand RELOAD proposal is 95% P2P functions and with a > little > > bit 5% SIP usage, since most of the functions originally designed in SIP > > protocol have been migrated into P2P layer. > > I don't really know what that means. > > RELOAD is about arranging for a channel to teh peer over which SIP can then > flow. It doesn't seem to me that that subsumes most of SIP but YMMV. > > -Ekr > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --0016364eccbe35634e048ac253a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Where can I find more information on the RELOAD proposal?

Sorry for my ignorance but is this the main proposed way for P2P SIP or i= s it part of many proposals?

I'm a bit lost as= to where things are at (although I joined the list to learn a bit more).

I've found lots of historical information on the P2= P SIP idea but just not sure where it's at now (July 2010).

On Wed, Jul 7, 2010 at 12:40 AM, Eric Rescorla <ekr@rtfm.com> wrote:

2010/7/6 Xianghan Zheng <xianghan.zheng@uia.no>:

> Hi All,
>
> I=A0get questions when i=A0quick review=A0RELOAD v8 proposals:
>
> (1) RELOAD mention that central enrollment server is used for the gene= ration
> of Node-ID (Section 3.5.2), However,=A0it looks not mention=A0how it > is=A0calculated. By hashing the SIP URI? Or random assignment?

" One or more Node-IDs which MUST be cryptographically random =A0 =A0 =A0[RFC4086]. =A0Each MUST be chosen by the enrollment server in s= uch a
=A0 =A0 =A0way that they are unpredictable to the requesting user. =A0Each= is
=A0 =A0 =A0placed in the subjectAltName using the uniformResourceIdentifie= r
=A0 =A0 =A0type and MUST contain RELOAD URIs as described in Section 13.13=
=A0 =A0 =A0and MUST contain a Destination list with a single entry of type=
=A0 =A0 =A0"node_id"."

> (2)=A0Can i understand RELOAD proposal is 95% P2P functions and with a= little
> bit 5% SIP usage,=A0since most of the functions originally designed=A0= in SIP
> protocol=A0have been migrated into P2P layer.

I don't really know what that means.

RELOAD is about arranging for a channel to teh peer over which SIP can then=
flow. It doesn't seem to me that that subsumes most of SIP but YMMV.
-Ekr
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip

--0016364eccbe35634e048ac253a6-- From xianghan.zheng@uia.no Wed Jul 7 14:55: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 740DD3A699C for ; Wed, 7 Jul 2010 14:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.328 X-Spam-Level: * X-Spam-Status: No, score=1.328 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 CAvqEabTIIWx for ; Wed, 7 Jul 2010 14:55:54 -0700 (PDT) Received: from pat.uia.no (pat.uia.no [158.36.80.144]) by core3.amsl.com (Postfix) with ESMTP id 5F20B3A6991 for ; Wed, 7 Jul 2010 14:55:53 -0700 (PDT) Received: from [158.36.80.152] (helo=mail-mx3.uia.no) by pat.uia.no with esmtp (Exim 4.69) (envelope-from ) id 1OWcay-0000kQ-My for p2psip@ietf.org; Wed, 07 Jul 2010 23:55:56 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mail-mx3.uia.no) by mail-mx3.uia.no with esmtp (Exim 4.69) (envelope-from ) id 1OWcay-0003IP-Li for p2psip@ietf.org; Wed, 07 Jul 2010 23:55:56 +0200 Received: from htkrs01.uia.no ([158.36.36.223]) by mail-mx3.uia.no with esmtp (Exim 4.69) (envelope-from ) id 1OWcau-0003I5-SQ for p2psip@ietf.org; Wed, 07 Jul 2010 23:55:56 +0200 Received: from exchkrs01.uia.no ([fe80::e9bc:692e:658e:7f60]) by htkrs01.uia.no ([fe80::acd9:3dff:b867:3dc8%12]) with mapi; Wed, 7 Jul 2010 23:55:43 +0200 From: Xianghan Zheng To: "p2psip@ietf.org" Date: Wed, 7 Jul 2010 23:54:38 +0200 Thread-Topic: P2PSIP Digest, Vol 43, Issue 2 Thread-Index: AcseBwPSbzq2VFwDQaiXTxPvTz1FmwAF/sSf Message-ID: References: In-Reply-To: Accept-Language: zh-CN, nb-NO Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, nb-NO Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-SA-Exim-Version: 4.2.1 (built Thu, 17 Jul 2008 09:48:05 +0200) Subject: [P2PSIP] =?big5?b?tarOYDogUDJQU0lQIERpZ2VzdCwgVm9sIDQzLCBJc3N1?= =?big5?b?ZSAy?= 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, 07 Jul 2010 21:55:55 -0000 eW91IHNob3VsZCBmaW5kIG1vc3Qgb2YgdGhlIGRvY3VtZW50YXRpb24gaW4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy93Zy9wMnBzaXAvICAgR29vZCBsdWNrLg0KDQpSZWdhcmRzLA0KWGlh bmdoYW4NCg0KTWVzc2FnZTogMQ0KRGF0ZTogV2VkLCA3IEp1bCAyMDEwIDA5OjQ1OjExICswODAw DQpGcm9tOiBBbmR5IFNhdmFnZSA8YW5keUBibHVld2lyZS5uZXQubno+DQpTdWJqZWN0OiBSZTog W1AyUFNJUF0gSUQgZ2VuZXJhdGlvbiBhbmQgUDJQIGxheWVyIGZ1bmN0aW9uIHF1ZXN0aW9ucw0K VG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCkNjOiBYaWFuZ2hhbiBaaGVuZyA8eGlh bmdoYW4uemhlbmdAdWlhLm5vPiwgInAycHNpcEBpZXRmLm9yZyINCiAgICAgICAgPHAycHNpcEBp ZXRmLm9yZz4NCk1lc3NhZ2UtSUQ6DQogICAgICAgIDxBQU5Ma1RpbUc3VUc2WUNBN0k5ZERFUUll aktVbFN0bjN1N0F6RGZPZFJwM2tAbWFpbC5nbWFpbC5jb20+DQpDb250ZW50LVR5cGU6IHRleHQv cGxhaW47IGNoYXJzZXQ9Imlzby04ODU5LTEiDQoNCldoZXJlIGNhbiBJIGZpbmQgbW9yZSBpbmZv cm1hdGlvbiBvbiB0aGUgUkVMT0FEIHByb3Bvc2FsPw0KDQpTb3JyeSBmb3IgbXkgaWdub3JhbmNl IGJ1dCBpcyB0aGlzIHRoZSBtYWluIHByb3Bvc2VkIHdheSBmb3IgUDJQIFNJUCBvciBpcw0KaXQg cGFydCBvZiBtYW55IHByb3Bvc2Fscz8NCg0KSSdtIGEgYml0IGxvc3QgYXMgdG8gd2hlcmUgdGhp bmdzIGFyZSBhdCAoYWx0aG91Z2ggSSBqb2luZWQgdGhlIGxpc3QgdG8NCmxlYXJuIGEgYml0IG1v cmUpLg0KDQpJJ3ZlIGZvdW5kIGxvdHMgb2YgaGlzdG9yaWNhbCBpbmZvcm1hdGlvbiBvbiB0aGUg UDJQIFNJUCBpZGVhIGJ1dCBqdXN0IG5vdA0Kc3VyZSB3aGVyZSBpdCdzIGF0IG5vdyAoSnVseSAy MDEwKS4NCg0KT24gV2VkLCBKdWwgNywgMjAxMCBhdCAxMjo0MCBBTSwgRXJpYyBSZXNjb3JsYSA8 ZWtyQHJ0Zm0uY29tPiB3cm90ZToNCg0KPiAyMDEwLzcvNiBYaWFuZ2hhbiBaaGVuZyA8eGlhbmdo YW4uemhlbmdAdWlhLm5vPjoNCj4gPiBIaSBBbGwsDQo+ID4NCj4gPiBJIGdldCBxdWVzdGlvbnMg d2hlbiBpIHF1aWNrIHJldmlldyBSRUxPQUQgdjggcHJvcG9zYWxzOg0KPiA+DQo+ID4gKDEpIFJF TE9BRCBtZW50aW9uIHRoYXQgY2VudHJhbCBlbnJvbGxtZW50IHNlcnZlciBpcyB1c2VkIGZvciB0 aGUNCj4gZ2VuZXJhdGlvbg0KPiA+IG9mIE5vZGUtSUQgKFNlY3Rpb24gMy41LjIpLCBIb3dldmVy LCBpdCBsb29rcyBub3QgbWVudGlvbiBob3cgaXQNCj4gPiBpcyBjYWxjdWxhdGVkLiBCeSBoYXNo aW5nIHRoZSBTSVAgVVJJPyBPciByYW5kb20gYXNzaWdubWVudD8NCj4NCj4NCj4gIiBPbmUgb3Ig bW9yZSBOb2RlLUlEcyB3aGljaCBNVVNUIGJlIGNyeXB0b2dyYXBoaWNhbGx5IHJhbmRvbQ0KPiAg ICAgIFtSRkM0MDg2XS4gIEVhY2ggTVVTVCBiZSBjaG9zZW4gYnkgdGhlIGVucm9sbG1lbnQgc2Vy dmVyIGluIHN1Y2ggYQ0KPiAgICAgIHdheSB0aGF0IHRoZXkgYXJlIHVucHJlZGljdGFibGUgdG8g dGhlIHJlcXVlc3RpbmcgdXNlci4gIEVhY2ggaXMNCj4gICAgICBwbGFjZWQgaW4gdGhlIHN1Ympl Y3RBbHROYW1lIHVzaW5nIHRoZSB1bmlmb3JtUmVzb3VyY2VJZGVudGlmaWVyDQo+ICAgICAgdHlw ZSBhbmQgTVVTVCBjb250YWluIFJFTE9BRCBVUklzIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEz LjEzDQo+ICAgICAgYW5kIE1VU1QgY29udGFpbiBhIERlc3RpbmF0aW9uIGxpc3Qgd2l0aCBhIHNp bmdsZSBlbnRyeSBvZiB0eXBlDQo+ICAgICAgIm5vZGVfaWQiLiINCj4NCj4NCj4gPiAoMikgQ2Fu IGkgdW5kZXJzdGFuZCBSRUxPQUQgcHJvcG9zYWwgaXMgOTUlIFAyUCBmdW5jdGlvbnMgYW5kIHdp dGggYQ0KPiBsaXR0bGUNCj4gPiBiaXQgNSUgU0lQIHVzYWdlLCBzaW5jZSBtb3N0IG9mIHRoZSBm dW5jdGlvbnMgb3JpZ2luYWxseSBkZXNpZ25lZCBpbiBTSVANCj4gPiBwcm90b2NvbCBoYXZlIGJl ZW4gbWlncmF0ZWQgaW50byBQMlAgbGF5ZXIuDQo+DQo+IEkgZG9uJ3QgcmVhbGx5IGtub3cgd2hh dCB0aGF0IG1lYW5zLg0KPg0KPiBSRUxPQUQgaXMgYWJvdXQgYXJyYW5naW5nIGZvciBhIGNoYW5u ZWwgdG8gdGVoIHBlZXIgb3ZlciB3aGljaCBTSVAgY2FuIHRoZW4NCj4gZmxvdy4gSXQgZG9lc24n dCBzZWVtIHRvIG1lIHRoYXQgdGhhdCBzdWJzdW1lcyBtb3N0IG9mIFNJUCBidXQgWU1NVi4NCj4N Cj4gLUVrcg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBQMlBTSVAgbWFpbGluZyBsaXN0DQo+IFAyUFNJUEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPg0KLS0tLS0tLS0tLS0tLS0gbmV4 dCBwYXJ0IC0tLS0tLS0tLS0tLS0tDQpBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4u DQpVUkw6IDxodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcDJwc2lwL2F0dGFj aG1lbnRzLzIwMTAwNzA3L2UwMjg0NDVlL2F0dGFjaG1lbnQuaHRtPg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClAyUFNJUCBtYWlsaW5nIGxpc3QNClAyUFNJUEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg0KDQpFbmQgb2YgUDJQU0lQ IERpZ2VzdCwgVm9sIDQzLCBJc3N1ZSAyDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioq From xianghan.zheng@uia.no Thu Jul 8 04:14:05 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 E7BFD3A6A4A for ; Thu, 8 Jul 2010 04:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.889 X-Spam-Level: *** X-Spam-Status: No, score=3.889 tagged_above=-999 required=5 tests=[AWL=-2.560, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, 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 zSDNgu1lKD0x for ; Thu, 8 Jul 2010 04:14:04 -0700 (PDT) Received: from pat.uia.no (pat.uia.no [158.36.80.144]) by core3.amsl.com (Postfix) with ESMTP id 0BA063A6A5B for ; Thu, 8 Jul 2010 04:14:02 -0700 (PDT) Received: from [158.36.80.151] (helo=mail-mx2.uia.no) by pat.uia.no with esmtp (Exim 4.69) (envelope-from ) id 1OWp3N-000279-A9; Thu, 08 Jul 2010 13:14:05 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=mail-mx2.uia.no) by mail-mx2.uia.no with esmtp (Exim 4.69) (envelope-from ) id 1OWp3N-0002So-5c; Thu, 08 Jul 2010 13:14:05 +0200 Received: from htkrs01.uia.no ([158.36.36.223]) by mail-mx2.uia.no with esmtp (Exim 4.69) (envelope-from ) id 1OWp3M-0002SJ-8z; Thu, 08 Jul 2010 13:14:05 +0200 Received: from exchkrs01.uia.no ([fe80::e9bc:692e:658e:7f60]) by htkrs01.uia.no ([fe80::acd9:3dff:b867:3dc8%12]) with mapi; Thu, 8 Jul 2010 13:13:51 +0200 From: Xianghan Zheng To: Eric Rescorla Date: Thu, 8 Jul 2010 13:13:50 +0200 Thread-Topic: [P2PSIP] ID generation and P2P layer function questions Thread-Index: AcsdKfG4ixjy10ZGRB29OUxrMHjHhwBY0s4H Message-ID: References: , In-Reply-To: Accept-Language: zh-CN, nb-NO Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, nb-NO Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-SA-Exim-Version: 4.2.1 (built Thu, 17 Jul 2008 09:48:05 +0200) Cc: "p2psip@ietf.org" Subject: [P2PSIP] =?gb2312?b?tPC4tDogIElEIGdlbmVyYXRpb24gYW5kIFAyUCBsYXll?= =?gb2312?b?ciBmdW5jdGlvbiBxdWVzdGlvbnM=?= 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, 08 Jul 2010 11:14:05 -0000 ICAgICAiIE9uZSBvciBtb3JlIE5vZGUtSURzIHdoaWNoIE1VU1QgYmUgY3J5cHRvZ3JhcGhpY2Fs bHkgcmFuZG9tDQogICAgICBbUkZDNDA4Nl0uICBFYWNoIE1VU1QgYmUgY2hvc2VuIGJ5IHRoZSBl bnJvbGxtZW50IHNlcnZlciBpbiBzdWNoIGENCiAgICAgIHdheSB0aGF0IHRoZXkgYXJlIHVucHJl ZGljdGFibGUgdG8gdGhlIHJlcXVlc3RpbmcgdXNlci4gIEVhY2ggaXMNCiAgICAgIHBsYWNlZCBp biB0aGUgc3ViamVjdEFsdE5hbWUgdXNpbmcgdGhlIHVuaWZvcm1SZXNvdXJjZUlkZW50aWZpZXIN CiAgICAgIHR5cGUgYW5kIE1VU1QgY29udGFpbiBSRUxPQUQgVVJJcyBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiAxMy4xMw0KICAgICAgYW5kIE1VU1QgY29udGFpbiBhIERlc3RpbmF0aW9uIGxpc3Qg d2l0aCBhIHNpbmdsZSBlbnRyeSBvZiB0eXBlDQogICAgICAibm9kZV9pZCIuIg0KDQpUaGF0IG1l YW5zLCB0aGUgc291cmNlIChhbGljZUBvcGVyYXRlMS5jb20pLCB3aG8gd2FudHMgdG8gc2VuZCBJ TlZJVEUgdG8gZGVzdGluYXRpb24gKEJvYkBvcGVyYXRlMi5jb20pLCBuZWVkcyB0byBmaXJzdCBh c2sgZW5yb2xsbWVudCBzZXJ2ZXIgIndoYXQgaXMgdGhlIElEIG9mIHRoZSBkZXN0aW5hdGlvbj8i LCBhbmQgdGhlbiBzZW5kcyBvdXQgdGhlIHJlcXVlc3QgdG8gdGhlIG92ZXJsYXk/Ig0KDQoNCiAg ICAgICAgUkVMT0FEIGlzIGFib3V0IGFycmFuZ2luZyBmb3IgYSBjaGFubmVsIHRvIHRlaCBwZWVy IG92ZXIgd2hpY2ggU0lQIGNhbiB0aGVuDQogICAgICAgIGZsb3cuIEl0IGRvZXNuJ3Qgc2VlbSB0 byBtZSB0aGF0IHRoYXQgc3Vic3VtZXMgbW9zdCBvZiBTSVAgYnV0IFlNTVYuDQoNClllcywgaSBh Z3JlZS4gSG93ZXZlciwgd2hhdCBpIG1lYW5zIGlzOiBTSVAgbWVzc2FnZSBpbiB0aGUgdXBwZXIg bGF5ZXIgbG9va3MgdXNlbGVzcyBpbiB0aGUgY29ubmVjdGlvbiAoSXQgbWlnaHQgYmUgZWFzaWVy IGZvciBpbnRlcndvcmtpbmcgb3IgYWRvcHQgd2l0aCBTSVAgVUEuKSAgRm9yIGV4YW1wbGUsIFNJ UCBwcm90b2NvbCBoYXZlIGEgVmlhIGhlYWRlciwgcmVjb3JkaW5nIHRoZSBpbnRlcm1lZGlhdGUg cm91dGVzLiBJbiBSRUxPQUQgc29sdXRpb24sIHRoaXMgInZpYSIgaGVhZGVyIHdvdWxkIGJlIGVt cHR5LiBBbmQgYWxsIHRoZSBmdW5jdGlvbnMgYXJlIG1pZ3JhdGVkIGludG8gdGhlIFAyUCBsYXll ci4gICANCg0KU29ycnkgaWYgaSB1bmRlcnN0YW5kIHdyb25nLiANCg0KUmVnYXJkcywNClhpYW5n aGFuIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBF cmljIFJlc2NvcmxhIFtla3JAcnRmbS5jb21dDQq3osvNyrG85DogMjAxMMTqN9TCNsjVIDE4OjQw DQrK1bz+yMs6IFhpYW5naGFuIFpoZW5nDQqzrcvNOiBwMnBzaXBAaWV0Zi5vcmcNCtb3zOI6IFJl OiBbUDJQU0lQXSBJRCBnZW5lcmF0aW9uIGFuZCBQMlAgbGF5ZXIgZnVuY3Rpb24gcXVlc3Rpb25z DQoNCjIwMTAvNy82IFhpYW5naGFuIFpoZW5nIDx4aWFuZ2hhbi56aGVuZ0B1aWEubm8+Og0KPiBI aSBBbGwsDQo+DQo+IEkgZ2V0IHF1ZXN0aW9ucyB3aGVuIGkgcXVpY2sgcmV2aWV3IFJFTE9BRCB2 OCBwcm9wb3NhbHM6DQo+DQo+ICgxKSBSRUxPQUQgbWVudGlvbiB0aGF0IGNlbnRyYWwgZW5yb2xs bWVudCBzZXJ2ZXIgaXMgdXNlZCBmb3IgdGhlIGdlbmVyYXRpb24NCj4gb2YgTm9kZS1JRCAoU2Vj dGlvbiAzLjUuMiksIEhvd2V2ZXIsIGl0IGxvb2tzIG5vdCBtZW50aW9uIGhvdyBpdA0KPiBpcyBj YWxjdWxhdGVkLiBCeSBoYXNoaW5nIHRoZSBTSVAgVVJJPyBPciByYW5kb20gYXNzaWdubWVudD8N Cg0KDQoiIE9uZSBvciBtb3JlIE5vZGUtSURzIHdoaWNoIE1VU1QgYmUgY3J5cHRvZ3JhcGhpY2Fs bHkgcmFuZG9tDQogICAgICBbUkZDNDA4Nl0uICBFYWNoIE1VU1QgYmUgY2hvc2VuIGJ5IHRoZSBl bnJvbGxtZW50IHNlcnZlciBpbiBzdWNoIGENCiAgICAgIHdheSB0aGF0IHRoZXkgYXJlIHVucHJl ZGljdGFibGUgdG8gdGhlIHJlcXVlc3RpbmcgdXNlci4gIEVhY2ggaXMNCiAgICAgIHBsYWNlZCBp biB0aGUgc3ViamVjdEFsdE5hbWUgdXNpbmcgdGhlIHVuaWZvcm1SZXNvdXJjZUlkZW50aWZpZXIN CiAgICAgIHR5cGUgYW5kIE1VU1QgY29udGFpbiBSRUxPQUQgVVJJcyBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiAxMy4xMw0KICAgICAgYW5kIE1VU1QgY29udGFpbiBhIERlc3RpbmF0aW9uIGxpc3Qg d2l0aCBhIHNpbmdsZSBlbnRyeSBvZiB0eXBlDQogICAgICAibm9kZV9pZCIuIg0KDQoNCj4gKDIp IENhbiBpIHVuZGVyc3RhbmQgUkVMT0FEIHByb3Bvc2FsIGlzIDk1JSBQMlAgZnVuY3Rpb25zIGFu ZCB3aXRoIGEgbGl0dGxlDQo+IGJpdCA1JSBTSVAgdXNhZ2UsIHNpbmNlIG1vc3Qgb2YgdGhlIGZ1 bmN0aW9ucyBvcmlnaW5hbGx5IGRlc2lnbmVkIGluIFNJUA0KPiBwcm90b2NvbCBoYXZlIGJlZW4g bWlncmF0ZWQgaW50byBQMlAgbGF5ZXIuDQoNCkkgZG9uJ3QgcmVhbGx5IGtub3cgd2hhdCB0aGF0 IG1lYW5zLg0KDQpSRUxPQUQgaXMgYWJvdXQgYXJyYW5naW5nIGZvciBhIGNoYW5uZWwgdG8gdGVo IHBlZXIgb3ZlciB3aGljaCBTSVAgY2FuIHRoZW4NCmZsb3cuIEl0IGRvZXNuJ3Qgc2VlbSB0byBt ZSB0aGF0IHRoYXQgc3Vic3VtZXMgbW9zdCBvZiBTSVAgYnV0IFlNTVYuDQoNCi1Fa3I= From davidbryan@gmail.com Thu Jul 8 07:59: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 8D1903A6ADF for ; Thu, 8 Jul 2010 07:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDlon59kX7AB for ; Thu, 8 Jul 2010 07:58:59 -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 432783A6AD2 for ; Thu, 8 Jul 2010 07:58:59 -0700 (PDT) Received: by gxk3 with SMTP id 3so487658gxk.31 for ; Thu, 08 Jul 2010 07:59:00 -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:content-type; bh=feFiBvf1IM/IMQzbJOZRaVpoUOnwQk/wfZp3t6pq0xc=; b=oIPykz6agbyMcUkrSTxMKtyXINai7OBjprpPrD4tq/VcUPwkVXAOnVzFYULDVxe5zD pJDZGl7JOb8E0CCyaxXHJK9jdyaYxZr7/3Lc50ECRDmRfVmRxTaZ6t71rX2qV/mbJAJ7 BeQCnmkegxrP3DDzTXIiAxS9bvOupcVAy32e8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=bcaGmy1kldW5pKPP1Vz4wpUV44QcoCcg3OWtVyPxgmTzDRzgewCGYacezy6a5TEEzY lCh/uY7KquSD9r3YWAlKT/h95WbBmQo/nI/eUhxKpdvKQCHvarH30J39POZA7vwa//pp UC0I8wanMaLEIiWwoazDYfQBCvc6hHyXbIoq4= MIME-Version: 1.0 Received: by 10.150.163.8 with SMTP id l8mr463514ybe.356.1278601139427; Thu, 08 Jul 2010 07:58:59 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.150.136.3 with HTTP; Thu, 8 Jul 2010 07:58:59 -0700 (PDT) Date: Thu, 8 Jul 2010 10:58:59 -0400 X-Google-Sender-Auth: 82GPSIKe7bToY3h9O4R3U0-35wg Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Possible problem with the extension mechanism on RELOAD? (and other places lengths might help) 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, 08 Jul 2010 14:59:00 -0000 So looking at the extension mechanism in 5.3.3...is there a reason that the MessageExtension object (5.3.3) has no length? I may have just missed something obvious, but it seems it needs to have one, if you want to allow multiple extensions where intermediate peers might not understand the opaque data. If for example we had two extensions, a message (I'll use a join for this example) might look like: Forwarding Header Message Contents message_code message_body JoinReq joining_peer_id (NodeID) overlay_specific_data (variable length) extensions ....extension 1.... ....extension 2.... Security Block Let's take a hypothetical case where a peer receiving this understands extension 2, but not extension 1. Even if extension 1 isn't critical and it knows the type, since what follows is opaque data, if it doesn't understand the extension, how does it know how long that block of opaque data is before getting to extension 2? Perhaps we need to change MessageExtension in 5.3.3. to include a length prior to the opaque data? While we're on this, there are several places where the parser seems to need to know about overlay specific/generic data just to to parse. The one above seems like it truly won't work without a length (since we explicitly want to allow for non-critical extensions), but others, for example the variable overlay_specific_data in some messages (for example this join) seem to imply that while it will work, the low level parser itself needs to know about the overlay specific data (since this can vary by overlay, not implementation). A parser that doesn't support that overlay parameter can't even parse the message (I don't think it can even know where the security block starts, so it technically can't even verify the signature, unless it reads backwards from the end or something, correct?) It seems like you need to have the extension-specific/overlay-specific code inside the basic parser...or am I missing something? (i.e., you can't write a generic parser that can parse any message, it needs to have contextual awareness) If this was a deliberate design decision it seems problematic. I personally don't really like the idea that a parser needs to understand the overlay specific data just to parse the message. Obviously you can do this with plug in code or something, but then we are forcing a particular implementation/design in the design of the protocol, and the extra bits (lengths) here and there that would allow a parser to process a message without the extensions simply aren't that heavy. It seems like a better design to allow a basic RELOAD parser to parse any message, passing specific data up to be decoded by higher levels. David (as individual) From davidbryan@gmail.com Thu Jul 8 12:34: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 54FF23A6B70 for ; Thu, 8 Jul 2010 12:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 2kFmgAWF62Lo for ; Thu, 8 Jul 2010 12:34:54 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 0B7593A6B82 for ; Thu, 8 Jul 2010 12:34:32 -0700 (PDT) Received: by gwj15 with SMTP id 15so725619gwj.31 for ; Thu, 08 Jul 2010 12:34:17 -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:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=zmORGcwMKQDBCaP9o/CP5KJC2TTfdZ7Leed0NwAbzxs=; b=kZU2PbCTRy88OhgSQcRIquK22Vmsfbt671k4cxHGvp1KtblHsZF6IgzBOsK+3uc+cx o3egCayEK4gbB+rxPaHc/CM5kZq+du5QQ/sYymA6odkd/SBGtyxKzDEIsTVMN8JGtrob bPK6N7w/S+S8lUmz1P/4aGiE9AMCEX/MwXVQo= 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; b=EylNGSi7mZrGQH0yfk/jyaBNva0auqUcIkTgZPLvTJbFjhK8GORli2iiunwJYNol1D SccmUFi3QLZwAGUj+JeMOsYmgbaOYt91Qr+koTTg4RBVm/WFeqYaklez0sPetKZRCT4/ S041pmHa1ZKdQXTc4hQi3zkUIvNSCriZGLO6s= MIME-Version: 1.0 Received: by 10.150.193.15 with SMTP id q15mr876985ybf.287.1278617654120; Thu, 08 Jul 2010 12:34:14 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.150.136.3 with HTTP; Thu, 8 Jul 2010 12:34:12 -0700 (PDT) Received: by 10.150.136.3 with HTTP; Thu, 8 Jul 2010 12:34:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Jul 2010 15:34:12 -0400 X-Google-Sender-Auth: Nj2o3tfibgcFPFBCgEkN1T_qGHQ Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: multipart/alternative; boundary=000e0cdf1ba0143c62048ae55f89 Subject: Re: [P2PSIP] Possible problem with the extension mechanism on RELOAD? (and other places lengths might help) 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, 08 Jul 2010 19:34:55 -0000 --000e0cdf1ba0143c62048ae55f89 Content-Type: text/plain; charset=ISO-8859-1 So having a conversation with myself here as I think more about these issues... I take back what I said about the overlay specific data. This info is coming from the config, without which a peer can't join anyway, and otherwise many things (including peerids) will need lengths, so I think the overlay specific data not having a size is fine as is, so long as the length is in the config. Love to hear other thoughts on it, however. Still think there is an issue with extension needing length, however... Thanks, David (as individual) On Jul 8, 2010 10:58 AM, "David A. Bryan" wrote: So looking at the extension mechanism in 5.3.3...is there a reason that the MessageExtension object (5.3.3) has no length? I may have just missed something obvious, but it seems it needs to have one, if you want to allow multiple extensions where intermediate peers might not understand the opaque data. If for example we had two extensions, a message (I'll use a join for this example) might look like: Forwarding Header Message Contents message_code message_body JoinReq joining_peer_id (NodeID) overlay_specific_data (variable length) extensions ....extension 1.... ....extension 2.... Security Block Let's take a hypothetical case where a peer receiving this understands extension 2, but not extension 1. Even if extension 1 isn't critical and it knows the type, since what follows is opaque data, if it doesn't understand the extension, how does it know how long that block of opaque data is before getting to extension 2? Perhaps we need to change MessageExtension in 5.3.3. to include a length prior to the opaque data? While we're on this, there are several places where the parser seems to need to know about overlay specific/generic data just to to parse. The one above seems like it truly won't work without a length (since we explicitly want to allow for non-critical extensions), but others, for example the variable overlay_specific_data in some messages (for example this join) seem to imply that while it will work, the low level parser itself needs to know about the overlay specific data (since this can vary by overlay, not implementation). A parser that doesn't support that overlay parameter can't even parse the message (I don't think it can even know where the security block starts, so it technically can't even verify the signature, unless it reads backwards from the end or something, correct?) It seems like you need to have the extension-specific/overlay-specific code inside the basic parser...or am I missing something? (i.e., you can't write a generic parser that can parse any message, it needs to have contextual awareness) If this was a deliberate design decision it seems problematic. I personally don't really like the idea that a parser needs to understand the overlay specific data just to parse the message. Obviously you can do this with plug in code or something, but then we are forcing a particular implementation/design in the design of the protocol, and the extra bits (lengths) here and there that would allow a parser to process a message without the extensions simply aren't that heavy. It seems like a better design to allow a basic RELOAD parser to parse any message, passing specific data up to be decoded by higher levels. David (as individual) --000e0cdf1ba0143c62048ae55f89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

So having a conversation with myself here as I think more about these is= sues...

I take back what I said about the overlay specific data. This info is co= ming from the config, without which a peer can't join anyway, and other= wise many things (including peerids) will need lengths, so I think the over= lay specific data not having a size is fine as is, so long as the length is= in the config. Love to hear other thoughts on it, however.

Still think there is an issue with extension needing length, however...<= /p>

Thanks,

David (as individual)

On Jul 8, 2010 10:58 AM, "David A. Bryan&= quot; <dbryan@ethernot.org>= ; wrote:

So looking at the extension mechanism in 5.3.3...is there a= reason
that the MessageExtension object (5.3.3) has no length? I may have
just missed something obvious, but it seems it needs to have one, if
you want to allow multiple extensions where intermediate peers might
not understand the opaque data. If for example we had two extensions,
a message (I'll use a join for this example) might look like:

Forwarding Header
Message Contents
=A0message_code
=A0message_body
=A0 JoinReq
=A0 =A0 =A0joining_peer_id (NodeID)
=A0 =A0 =A0overlay_specific_data (variable length)
=A0extensions
=A0 =A0 =A0....extension 1....
=A0 =A0 =A0....extension 2....
Security Block

Let's take a hypothetical case where a peer receiving this understands<= br> extension 2, but not extension 1. Even if extension 1 isn't critical and it knows the type, since what follows is opaque data, if it
doesn't understand the extension, how does it know how long that block<= br> of opaque data is before getting to extension 2?

Perhaps we need to change MessageExtension in 5.3.3. to include a
length prior to the opaque data?

While we're on this, there are several places where the parser seems to need to know about overlay specific/generic data just to to parse.
The one above seems like it truly won't work without a length (since we explicitly want to allow for non-critical extensions), but others,
for example the variable overlay_specific_data in some messages (for
example this join) seem to imply that while it will work, the low
level parser itself needs to know about the overlay specific data
(since this can vary by overlay, not implementation). A parser that
doesn't support that overlay parameter can't even parse the message= (I
don't think it can even know where the security block starts, so it
technically can't even verify the signature, unless it reads backwards<= br> from the end or something, correct?)

It seems like you need to have the extension-specific/overlay-specific
code inside the basic parser...or am I missing something? (i.e., you
can't write a generic parser that can parse any message, it needs to have contextual awareness) If this was a deliberate design decision it
seems problematic. I personally don't really like the idea that a
parser needs to understand the overlay specific data just to parse the
message. Obviously you can do this with plug in code or something, but
then we are forcing a particular implementation/design in the design
of the protocol, and the extra bits (lengths) here and there that
would allow a parser to process a message without the extensions
simply aren't that heavy. It seems like a better design to allow a
basic RELOAD parser to parse any message, passing specific data up to
be decoded by higher levels.

David (as individual)

--000e0cdf1ba0143c62048ae55f89-- From fluffy@cisco.com Thu Jul 8 13:11: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 0A33E3A68AC for ; Thu, 8 Jul 2010 13:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.343 X-Spam-Level: X-Spam-Status: No, score=-110.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 Y1AuycKoJihI for ; Thu, 8 Jul 2010 13:11:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 78C4B3A689F for ; Thu, 8 Jul 2010 13:11:13 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALLNNUyrR7H+/2dsb2JhbACgMHGnS5puhSUEg3mESQ X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="556223045" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Jul 2010 20:11:18 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o68KBG3H006587; Thu, 8 Jul 2010 20:11:17 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Thu, 8 Jul 2010 14:11:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6726F956-FC9E-4558-9EDB-2E33935E589D@cisco.com> References: To: "David A. Bryan" X-Mailer: Apple Mail (2.1081) Cc: P2PSIP WG Subject: Re: [P2PSIP] Possible problem with the extension mechanism on RELOAD? (and other places lengths might help) 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, 08 Jul 2010 20:11:51 -0000 Agree with what you are getting at here but I think the draft is already = pretty much what you want and this is just a syntax confusion.=20 When the spec has a typedef like=20 typedef opaque ResourceId<0..2^8-1>; This results in bits on the wire that look like an 8 bit integer as the = length followed by that many byes of data. So any time we have a = variably length element generated by the < > operators, it includes the = length as well as the data.=20 So with that in mind, looking at section 5.3.3, the=20 MessageExtensions extensions<0..2^32-1>; will contain the length all *all* the extensions if a parser just wanted = to skip over them all. If it did not skip them all, the=20 opaque extension_contents<0..2^32-1>; will start with the length of the extension data so the parser can skip = over an extenuation it does not understand.=20 So given all that, does draft look reasonable. I completely agree an = peer needs to be able to know the length of an unknown extortion to be = able to step over it in parsing so if we can't do that, we need to fix = it.=20 On Jul 8, 2010, at 8:58 AM, David A. Bryan wrote: > So looking at the extension mechanism in 5.3.3...is there a reason > that the MessageExtension object (5.3.3) has no length? I may have > just missed something obvious, but it seems it needs to have one, if > you want to allow multiple extensions where intermediate peers might > not understand the opaque data. If for example we had two extensions, > a message (I'll use a join for this example) might look like: >=20 > Forwarding Header > Message Contents > message_code > message_body > JoinReq > joining_peer_id (NodeID) > overlay_specific_data (variable length) > extensions > ....extension 1.... > ....extension 2.... > Security Block >=20 > Let's take a hypothetical case where a peer receiving this understands > extension 2, but not extension 1. Even if extension 1 isn't critical > and it knows the type, since what follows is opaque data, if it > doesn't understand the extension, how does it know how long that block > of opaque data is before getting to extension 2? >=20 > Perhaps we need to change MessageExtension in 5.3.3. to include a > length prior to the opaque data? >=20 > While we're on this, there are several places where the parser seems > to need to know about overlay specific/generic data just to to parse. > The one above seems like it truly won't work without a length (since > we explicitly want to allow for non-critical extensions), but others, > for example the variable overlay_specific_data in some messages (for > example this join) seem to imply that while it will work, the low > level parser itself needs to know about the overlay specific data > (since this can vary by overlay, not implementation). A parser that > doesn't support that overlay parameter can't even parse the message (I > don't think it can even know where the security block starts, so it > technically can't even verify the signature, unless it reads backwards > from the end or something, correct?) >=20 > It seems like you need to have the extension-specific/overlay-specific > code inside the basic parser...or am I missing something? (i.e., you > can't write a generic parser that can parse any message, it needs to > have contextual awareness) If this was a deliberate design decision it > seems problematic. I personally don't really like the idea that a > parser needs to understand the overlay specific data just to parse the > message. Obviously you can do this with plug in code or something, but > then we are forcing a particular implementation/design in the design > of the protocol, and the extra bits (lengths) here and there that > would allow a parser to process a message without the extensions > simply aren't that heavy. It seems like a better design to allow a > basic RELOAD parser to parse any message, passing specific data up to > be decoded by higher levels. >=20 > David (as individual) > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From davidbryan@gmail.com Thu Jul 8 13:27: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 A36A73A688F for ; Thu, 8 Jul 2010 13:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 NNMyDqa1A126 for ; Thu, 8 Jul 2010 13:27:41 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 721CA3A6836 for ; Thu, 8 Jul 2010 13:27:41 -0700 (PDT) Received: by gwj15 with SMTP id 15so774568gwj.31 for ; Thu, 08 Jul 2010 13:27:42 -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:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=+iymaR+gwGa9RuzivUt6Gl9pbqs5ybCR3GffCGmVzds=; b=vFfbMfp/sLgh0GiMmnuPfYP1dMVsQMl2Vy5LVbFZoHONZbf+KrbVJ8lEkNubOf6Ip3 k9G0UqMqfQWWrlspN4e3oFdqv/0Vu4p0HEfe1Jnetj6/CegNkQgspqSihf3JaYwGJHhN iiCtIhVDyZjlbqiGGE9wTi3yhfjgrUocjS8y8= 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; b=L5xuF+ybhohEdZOAshW0NV+qFTkFYCuDDeinQOkP+HpvIvE5pFLOuAYMYTOCTX2hRd KDA1Y/EfCMW8bOzcHqrAtSjjSMsqyTueqn7m8o3cUD9m2xIRfQy6sNV0vrMpjOcRqsCP HD26Vgs0JsQ2ecVS62jti+Cj1ErvMiSmuFXko= MIME-Version: 1.0 Received: by 10.150.210.9 with SMTP id i9mr875583ybg.284.1278620862032; Thu, 08 Jul 2010 13:27:42 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.150.136.3 with HTTP; Thu, 8 Jul 2010 13:27:41 -0700 (PDT) Received: by 10.150.136.3 with HTTP; Thu, 8 Jul 2010 13:27:41 -0700 (PDT) In-Reply-To: References: <6726F956-FC9E-4558-9EDB-2E33935E589D@cisco.com> Date: Thu, 8 Jul 2010 16:27:41 -0400 X-Google-Sender-Auth: Dw1MNnmBBFAx7qmAoIFBHKa5h2g Message-ID: From: "David A. Bryan" To: Cullen Jennings Content-Type: multipart/alternative; boundary=000e0cd3551248ab6e048ae61e01 Cc: P2PSIP WG Subject: Re: [P2PSIP] Possible problem with the extension mechanism on RELOAD? (and other places lengths might help) 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, 08 Jul 2010 20:27:42 -0000 --000e0cd3551248ab6e048ae61e01 Content-Type: text/plain; charset=ISO-8859-1 In this case, definitely that's fine. Can you point out where in the spec it mentions opaque data encoding a length? I even looked for that in the TLS style syntax description again, since everything I was worried about in the draft made since if that was the case, but couldn't find it. I think we may have the very minor bug of needing to make the fact the length is encoded a bit more clear in the draft (or I'm just blind), but given this, my bigger concern is a non-issue. Thanks, that clears it up. David (as individual) On Jul 8, 2010 4:11 PM, "Cullen Jennings" wrote: Agree with what you are getting at here but I think the draft is already pretty much what you want and this is just a syntax confusion. When the spec has a typedef like typedef opaque ResourceId<0..2^8-1>; This results in bits on the wire that look like an 8 bit integer as the length followed by that many byes of data. So any time we have a variably length element generated by the < > operators, it includes the length as well as the data. So with that in mind, looking at section 5.3.3, the MessageExtensions extensions<0..2^32-1>; will contain the length all *all* the extensions if a parser just wanted to skip over them all. If it did not skip them all, the opaque extension_contents<0..2^32-1>; will start with the length of the extension data so the parser can skip over an extenuation it does not understand. So given all that, does draft look reasonable. I completely agree an peer needs to be able to know the length of an unknown extortion to be able to step over it in parsing so if we can't do that, we need to fix it. On Jul 8, 2010, at 8:58 AM, David A. Bryan wrote: > So looking at the extension mechanism in 5.3... > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --000e0cd3551248ab6e048ae61e01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

In this case, definitely that's fine. Can you point out where in the= spec it mentions opaque data encoding a length? I even looked for that in = the TLS style syntax description again, since everything I was worried abou= t in the draft made since if that was the case, but couldn't find it. <= /p>

I think we may have the very minor bug of needing to make the fact the l= ength is encoded a bit more clear in the draft (or I'm just blind), but= given this, my bigger concern is a non-issue. Thanks, that clears it up.

David (as individual)

On Jul 8, 2010 4:11 PM, "Cullen Jennings&= quot; <fluffy@cisco.com> wrot= e:

Agree with what you are getting at here but I think the draft is already pr= etty much what you want and this is just a syntax confusion.

When the spec has a typedef like

=A0 =A0 typedef opaque =A0 =A0 =A0 ResourceId<0..2^8-1>;

This results in bits on the wire that look like an 8 bit integer as the len= gth followed by that many byes of data. So any time we have a variably leng= th element generated by the < > operators, it includes the length as = well as the data.

So with that in mind, looking at section 5.3.3, the

=A0 MessageExtensions =A0 =A0 =A0extensions<0..2^32-1>;

will contain the length all *all* the extensions if a parser just wanted to= skip over them all. If it did not skip them all, the

=A0opaque =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0extension_contents<0..2^32-1&g= t;;

will start with the length of the extension data so the parser can skip ove= r an extenuation it does not understand.

So given all that, does draft look reasonable. I completely agree an peer n= eeds to be able to know the length of an unknown extortion to be able to st= ep over it in parsing so if we can't do that, we need to fix it.

On Jul 8, 2010, at 8:58 AM, David A.= Bryan wrote:

> So looking at the extension mechanism in 5.3...
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/c= ri/index.html

--000e0cd3551248ab6e048ae61e01-- From Even.roni@huawei.com Thu Jul 8 14:18:43 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 EDAEE3A6903 for ; Thu, 8 Jul 2010 14:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gE8IG0R6BTg for ; Thu, 8 Jul 2010 14:18:42 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6C8A13A68C5 for ; Thu, 8 Jul 2010 14:18:42 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5900CCCCJ03C@szxga01-in.huawei.com> for p2psip@ietf.org; Fri, 09 Jul 2010 05:18:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L590022OCJ021@szxga01-in.huawei.com> for p2psip@ietf.org; Fri, 09 Jul 2010 05:18:36 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-21-25.red.bezeqint.net [79.178.21.25]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5900FTOCIRGN@szxml01-in.huawei.com>; Fri, 09 Jul 2010 05:18:36 +0800 (CST) Date: Fri, 09 Jul 2010 00:18:00 +0300 From: Roni Even In-reply-to: To: "'David A. Bryan'" , 'Cullen Jennings' Message-id: <023601cb1ee3$10c7a540$3256efc0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8Rf48XYgKAHXHvVKZ2/iSQ)" Content-language: en-us Thread-index: Acse3A0Bp1J5k3FbSk2T+6qv/3MSeQABpRUA References: <6726F956-FC9E-4558-9EDB-2E33935E589D@cisco.com>

Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Possible problem with the extension mechanism on RELOAD? (and other places lengths might help) 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, 08 Jul 2010 21:18:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8Rf48XYgKAHXHvVKZ2/iSQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT David, It is in section 5.3.1.1 but I can agree that it is not clear enough and maybe some specific text would make it better. I assume that for fix length there opaque there is no length field and for variable length there is a length filed with size that will allow to list the actual size of the string. Roni Even From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of David A. Bryan Sent: Thursday, July 08, 2010 11:28 PM To: Cullen Jennings Cc: P2PSIP WG Subject: Re: [P2PSIP] Possible problem with the extension mechanism on RELOAD? (and other places lengths might help) In this case, definitely that's fine. Can you point out where in the spec it mentions opaque data encoding a length? I even looked for that in the TLS style syntax description again, since everything I was worried about in the draft made since if that was the case, but couldn't find it. I think we may have the very minor bug of needing to make the fact the length is encoded a bit more clear in the draft (or I'm just blind), but given this, my bigger concern is a non-issue. Thanks, that clears it up. David (as individual) On Jul 8, 2010 4:11 PM, "Cullen Jennings" wrote: Agree with what you are getting at here but I think the draft is already pretty much what you want and this is just a syntax confusion. When the spec has a typedef like typedef opaque ResourceId<0..2^8-1>; This results in bits on the wire that look like an 8 bit integer as the length followed by that many byes of data. So any time we have a variably length element generated by the < > operators, it includes the length as well as the data. So with that in mind, looking at section 5.3.3, the MessageExtensions extensions<0..2^32-1>; will contain the length all *all* the extensions if a parser just wanted to skip over them all. If it did not skip them all, the opaque extension_contents<0..2^32-1>; will start with the length of the extension data so the parser can skip over an extenuation it does not understand. So given all that, does draft look reasonable. I completely agree an peer needs to be able to know the length of an unknown extortion to be able to step over it in parsing so if we can't do that, we need to fix it. On Jul 8, 2010, at 8:58 AM, David A. Bryan wrote: > So looking at the extension mechanism in 5.3... > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Boundary_(ID_8Rf48XYgKAHXHvVKZ2/iSQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

David,

It is in section 5.3.1.1 but I can agree that it is not clear enough and maybe some specific text would make it better.

I assume that for fix length there opaque there is no length field and for variable length there is a length filed with size that will allow to list the actual size of the string.

Roni Even

From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of David A. Bryan
Sent: Thursday, July 08, 2010 11:28 PM
To: Cullen Jennings
Cc: P2PSIP WG
Subject: Re: [P2PSIP] Possible problem with the extension mechanism on RELOAD? (and other places lengths might help)

In this case, definitely that's fine. Can you point out where in the spec it mentions opaque data encoding a length? I even looked for that in the TLS style syntax description again, since everything I was worried about in the draft made since if that was the case, but couldn't find it.

I think we may have the very minor bug of needing to make the fact the length is encoded a bit more clear in the draft (or I'm just blind), but given this, my bigger concern is a non-issue. Thanks, that clears it up.

David (as individual)

On Jul 8, 2010 4:11 PM, "Cullen Jennings" <fluffy@cisco.com> wrote:

Agree with what you are getting at here but I think the draft is already pretty much what you want and this is just a syntax confusion.

When the spec has a typedef like

typedef opaque ResourceId<0..2^8-1>;

This results in bits on the wire that look like an 8 bit integer as the length followed by that many byes of data. So any time we have a variably length element generated by the < > operators, it includes the length as well as the data.

So with that in mind, looking at section 5.3.3, the

MessageExtensions extensions<0..2^32-1>;

will contain the length all *all* the extensions if a parser just wanted to skip over them all. If it did not skip them all, the

opaque extension_contents<0..2^32-1>;

will start with the length of the extension data so the parser can skip over an extenuation it does not understand.

So given all that, does draft look reasonable. I completely agree an peer needs to be able to know the length of an unknown extortion to be able to step over it in parsing so if we can't do that, we need to fix it.

On Jul 8, 2010, at 8:58 AM, David A. Bryan wrote:

> So looking at the extension mechanism in 5.3...

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

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

--Boundary_(ID_8Rf48XYgKAHXHvVKZ2/iSQ)-- From fluffy@cisco.com Thu Jul 8 14:39: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 DC9B73A6984 for ; Thu, 8 Jul 2010 14:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 9y1p+wCLA5t1 for ; Thu, 8 Jul 2010 14:39:37 -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 7AB923A697B for ; Thu, 8 Jul 2010 14:39:37 -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: AvsEAFPiNUyrR7Hu/2dsb2JhbACgMXGnFZprhSUEg3mESQ X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="155961077" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 08 Jul 2010 21:39:42 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o68LdfTg026953; Thu, 8 Jul 2010 21:39:41 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Thu, 8 Jul 2010 15:39:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6726F956-FC9E-4558-9EDB-2E33935E589D@cisco.com>

To: "David A. Bryan" X-Mailer: Apple Mail (2.1081) Cc: P2PSIP WG Subject: Re: [P2PSIP] Possible problem with the extension mechanism on RELOAD? (and other places lengths might help) 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, 08 Jul 2010 21:39:39 -0000 On Jul 8, 2010, at 2:27 PM, David A. Bryan wrote: > I think we may have the very minor bug of needing to make the fact the = length is encoded a bit more clear in the draft (or I'm just blind), I tried to clear that up in the next version of the draft.=20 From ekr@rtfm.com Thu Jul 8 21:15: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 72F5A3A6B6E for ; Thu, 8 Jul 2010 21:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.971 X-Spam-Level: ** X-Spam-Status: No, score=2.971 tagged_above=-999 required=5 tests=[AWL=-2.348, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, 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 gNEavo8ZuiEY for ; Thu, 8 Jul 2010 21:15:52 -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 5CB743A67B5 for ; Thu, 8 Jul 2010 21:15:52 -0700 (PDT) Received: by gxk3 with SMTP id 3so1051490gxk.31 for ; Thu, 08 Jul 2010 21:15:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.113.9 with SMTP id l9mr2731754agc.24.1278648953608; Thu, 08 Jul 2010 21:15:53 -0700 (PDT) Received: by 10.90.161.5 with HTTP; Thu, 8 Jul 2010 21:15:53 -0700 (PDT) In-Reply-To: References:

Date: Thu, 8 Jul 2010 21:15:53 -0700 Message-ID: From: Eric Rescorla To: Xianghan Zheng Content-Type: multipart/alternative; boundary=0016e64604eeac1a5e048aeca84b Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] =?gb2312?b?tPC4tDogIElEIGdlbmVyYXRpb24gYW5kIFAyUCBsYXll?= =?gb2312?b?ciBmdW5jdGlvbiBxdWVzdGlvbnM=?= 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, 09 Jul 2010 04:15:55 -0000 --0016e64604eeac1a5e048aeca84b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable 2010/7/8 Xianghan Zheng > " One or more Node-IDs which MUST be cryptographically random > [RFC4086]. Each MUST be chosen by the enrollment server in such a > way that they are unpredictable to the requesting user. Each is > placed in the subjectAltName using the uniformResourceIdentifier > type and MUST contain RELOAD URIs as described in Section 13.13 > and MUST contain a Destination list with a single entry of type > "node_id"." > > That means, the source (alice@operate1.com), who wants to send INVITE to > destination (Bob@operate2.com), needs to first ask enrollment server "wha= t > is the ID of the destination?", and then sends out the request to the > overlay?" No. You publish your mapping in the overlay. > RELOAD is about arranging for a channel to teh peer over which SIP > can then > flow. It doesn't seem to me that that subsumes most of SIP but YMM= V. > > Yes, i agree. However, what i means is: SIP message in the upper layer > looks useless in the connection (It might be easier for interworking or > adopt with SIP UA.) For example, SIP protocol have a Via header, recordi= ng > the intermediate routes. In RELOAD solution, this "via" header would be > empty. And all the functions are migrated into the P2P layer. > > Sorry if i understand wrong. > There's a lot more to SIP than routing. -Ekr > Regards, > Xianghan > ________________________________________ > =B7=A2=BC=FE=C8=CB: Eric Rescorla [ekr@rtfm.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C26=C8=D5 18:40 > =CA=D5=BC=FE=C8=CB: Xianghan Zheng > =B3=AD=CB=CD: p2psip@ietf.org > =D6=F7=CC=E2: Re: [P2PSIP] ID generation and P2P layer function questions > > 2010/7/6 Xianghan Zheng : > > Hi All, > > > > I get questions when i quick review RELOAD v8 proposals: > > > > (1) RELOAD mention that central enrollment server is used for the > generation > > of Node-ID (Section 3.5.2), However, it looks not mention how it > > is calculated. By hashing the SIP URI? Or random assignment? > > > " One or more Node-IDs which MUST be cryptographically random > [RFC4086]. Each MUST be chosen by the enrollment server in such a > way that they are unpredictable to the requesting user. Each is > placed in the subjectAltName using the uniformResourceIdentifier > type and MUST contain RELOAD URIs as described in Section 13.13 > and MUST contain a Destination list with a single entry of type > "node_id"." > > > > (2) Can i understand RELOAD proposal is 95% P2P functions and with a > little > > bit 5% SIP usage, since most of the functions originally designed in SI= P > > protocol have been migrated into P2P layer. > > I don't really know what that means. > > RELOAD is about arranging for a channel to teh peer over which SIP can th= en > flow. It doesn't seem to me that that subsumes most of SIP but YMMV. > > -Ekr > --0016e64604eeac1a5e048aeca84b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

2010/7/8 Xianghan Zheng <xianghan.zheng@uia.no>= ;

" One or more Node-IDs which MUST be = cryptographically random
[RFC4086]. Each MUST be chosen by the enrollment= server in such a
way that they are unpredictable to the requesting user= . Each is
placed in the subjectAltName using the uniformResource= Identifier
type and MUST contain RELOAD URIs as described in Sect= ion 13.13
and MUST contain a Destination list with a single entr= y of type
"node_id"."

That means, the source (alice@o= perate1.com), who wants to send INVITE to destination (Bob@operate2.com), needs to first ask enrollment se= rver "what is the ID of the destination?", and then sends out the= request to the overlay?"

No. You publish your mapping in the overlay.

RELOAD is about arranging for a channel to teh = peer over which SIP can then
flow. It doesn't seem to me that that subsu= mes most of SIP but YMMV.

Yes, i agree. However, what i means is: SIP message in the upper laye= r looks useless in the connection (It might be easier for interworking or a= dopt with SIP UA.) For example, SIP protocol have a Via header, recor= ding the intermediate routes. In RELOAD solution, this "via" head= er would be empty. And all the functions are migrated into the P2P layer.
Sorry if i understand wrong.

There'= s a lot more to SIP than routing.

-Ekr

&= nbsp;

Regards,
Xianghan
________________________________________
=B7=A2=BC=FE=C8=CB: Eric Rescorla [ekr@rtfm= .com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C26=C8=D5 18:40
=CA=D5=BC=FE=C8=CB: Xianghan Zheng
=B3=AD=CB=CD: p2psip@ietf.org
=D6=F7=CC=E2: Re: [P2PSIP] ID generation and P2P layer function questions

2010/7/6 Xianghan Zheng <xiangh= an.zheng@uia.no>:
> Hi All,
>
> I get questions when i quick review RELOAD v8 proposals:
>
> (1) RELOAD mention that central enrollment server is used for the gene= ration
> of Node-ID (Section 3.5.2), However, it looks not mention how it
> is calculated. By hashing the SIP URI? Or random assignment?

" One or more Node-IDs which MUST be cryptographically random
[RFC4086]. Each MUST be chosen by the enrollment= server in such a
way that they are unpredictable to the requesting user= . Each is
placed in the subjectAltName using the uniformResource= Identifier
type and MUST contain RELOAD URIs as described in Sect= ion 13.13
and MUST contain a Destination list with a single entr= y of type
"node_id"."

> (2) Can i understand RELOAD proposal is 95% P2P functions and with a l= ittle
> bit 5% SIP usage, since most of the functions originally designed in S= IP
> protocol have been migrated into P2P layer.

I don't really know what that means.

RELOAD is about arranging for a channel to teh peer over which SIP can then=
flow. It doesn't seem to me that that subsumes most of SIP but YMMV.
-Ekr

--0016e64604eeac1a5e048aeca84b-- From root@core3.amsl.com Sun Jul 11 22:45:12 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 4456A3A6A4D; Sun, 11 Jul 2010 22:45:03 -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: <20100712054509.4456A3A6A4D@core3.amsl.com> Date: Sun, 11 Jul 2010 22:45:03 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-service-discovery-01.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, 12 Jul 2010 05:45:13 -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 : Service Discovery Usage for REsource LOcation And Discovery (RELOAD) Author(s) : J. Maenpaa, G. Camarillo Filename : draft-ietf-p2psip-service-discovery-01.txt Pages : 14 Date : 2010-07-11 REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-01.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-service-discovery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-11223946.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Jul 11 22:45:14 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 274423A6A3C; Sun, 11 Jul 2010 22:45:08 -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: <20100712054512.274423A6A3C@core3.amsl.com> Date: Sun, 11 Jul 2010 22:45:09 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-self-tuning-02.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, 12 Jul 2010 05:45:14 -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 : A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) Author(s) : J. Maenpaa, et al. Filename : draft-ietf-p2psip-self-tuning-02.txt Pages : 20 Date : 2010-07-11 REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-self-tuning-02.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-self-tuning-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-11224307.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 08:00: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 8FF873A6989; Mon, 12 Jul 2010 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712150001.8FF873A6989@core3.amsl.com> Date: Mon, 12 Jul 2010 08:00:01 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-diagnostics-04.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, 12 Jul 2010 15:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : P2PSIP Overlay Diagnostics Author(s) : S. Yongchao, et al. Filename : draft-ietf-p2psip-diagnostics-04.txt Pages : 28 Date : 2010-07-12 This document describes mechanisms for P2PSIP diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-04.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-diagnostics-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12075305.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 15:15:02 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 526A83A687A; Mon, 12 Jul 2010 15: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: <20100712221502.526A83A687A@core3.amsl.com> Date: Mon, 12 Jul 2010 15:15:02 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-sip-05.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, 12 Jul 2010 22:15:02 -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 : A SIP Usage for RELOAD Author(s) : C. Jennings, et al. Filename : draft-ietf-p2psip-sip-05.txt Pages : 13 Date : 2010-07-12 This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-05.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-sip-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12150009.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 15:15:02 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 6CAD73A6A06; Mon, 12 Jul 2010 15: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: <20100712221502.6CAD73A6A06@core3.amsl.com> Date: Mon, 12 Jul 2010 15:15:02 -0700 (PDT) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-09.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, 12 Jul 2010 22:15:02 -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-09.txt Pages : 154 Date : 2010-07-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-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12150014.I-D@ietf.org> --NextPart-- From davidbryan@gmail.com Wed Jul 14 07:03: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 3B8393A6A1D for ; Wed, 14 Jul 2010 07:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdIKc65zfLdP for ; Wed, 14 Jul 2010 07:03:40 -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 7E6E73A6959 for ; Wed, 14 Jul 2010 07:03:40 -0700 (PDT) Received: by gxk3 with SMTP id 3so4332594gxk.31 for ; Wed, 14 Jul 2010 07:03:46 -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:content-type; bh=awSAW6gH03fQiAc+mxDeY3gI6r8IWf4Wd4nnxsoPqOw=; b=r0S/rML15tcXlNgs5webdF8a9o+fFGAlf7h0LgZnLLDT7A3iuNUrvNsc8qAG+e4GbO rmIbjhgurVOE+TOrutJkqHbRThVhzFTKzXDdcX6tHAv1wj7/Qshp8NPPdxc7mTKZ/piV gWgQIpmBtE5RncWC/W/32XE+LUUumng8HOb8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=M4cNZsSsz+WN+uPT192rE7qHejMTHxwW9hxzSJ/srRm6fcPgJTXFk05xCEx87UN92F suGj4NoGVOjIB0gTD+zFFdFdxWrijbpwFTeM+VOXWLuAkdwp38eJZiQWM7TftWtdHM1i DW39otFStvs1ZOEwPAa+4+kNPlMfQiAocX6d8= MIME-Version: 1.0 Received: by 10.151.40.7 with SMTP id s7mr9412436ybj.102.1279116226021; Wed, 14 Jul 2010 07:03:46 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.150.136.3 with HTTP; Wed, 14 Jul 2010 07:03:45 -0700 (PDT) Date: Wed, 14 Jul 2010 10:03:45 -0400 X-Google-Sender-Auth: WbbR2MZzk_jLwSYNn861wB2EiRg Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Draft P2PSIP agenda for IETF-78 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, 14 Jul 2010 14:03:41 -0000 As usual, subject to change, and if you already sent a request and we missed it, please send Brian and I an email. See everyone in Maastricht. David & Brian (as chairs) ---- P2PSIP Session, IETF 78 1740-1940, Brussels Conference Room Agenda Bash, chairs, :10, 17:40-17:50 RELOAD, draft-ietf-p2psip-base-09, Cullen Jennings, 1:15, 17:50-19:05 Diagnostics, draft-ietf-diagnostics-04, Presenter TBD, :20, 19:05-19:25 Disco, draft-knauf-p2psip-disco-00, Presenter TBD, :15, 19:25-19:40 From p2pnve2010@gmail.com Fri Jul 16 22:40:45 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 A60F83A684B for ; Fri, 16 Jul 2010 22:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 CryBrrd+aERT for ; Fri, 16 Jul 2010 22:39:52 -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 E3A333A6359 for ; Fri, 16 Jul 2010 22:39:51 -0700 (PDT) Received: by qyk1 with SMTP id 1so646155qyk.10 for ; Fri, 16 Jul 2010 22:39:20 -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=rrKQCIkAPkBdxs3kbDbhKHbiaaKvCqeh4+osqzu/zFo=; b=sUHnoOq/oA4VVghY/fq3TFzzRfO6bs8PZFRk6yFHT3aXdrKJ9v9pd8/N2WAhvMe249 vC+0VXL74/OP6wTJYIic5A484cNd9SA+jrZqCVOSv9bp9JffdAOVNEGjwFMhCz1lXWCV oCbpLzEiMGMh92HfYW3RTZCNmsRStS0ZQtLG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=S9PjnwXFZV+BB0mdPPFOvhnYrP946F445Ye2fMHwDwDOtxYWOlQ5hkgOCPjaizjBmZ RqWHmpo6QcJGw6ynK180FfjwH3hEOG7jQR9lFEaeBUGTJlH6zIPeNrdd9Sa1TRIK0cPS tp6Qkaej4Os8U/wDiRbJSRxD1994sS4ak+vFE= MIME-Version: 1.0 Received: by 10.224.122.234 with SMTP id m42mr1781725qar.235.1279345160786; Fri, 16 Jul 2010 22:39:20 -0700 (PDT) Received: by 10.229.21.7 with HTTP; Fri, 16 Jul 2010 22:39:20 -0700 (PDT) Date: Sat, 17 Jul 2010 13:39:20 +0800 Message-ID: From: p2pnve2010 To: p2psip@ietf.org Content-Type: multipart/alternative; boundary=00c09f89939bda9601048b8ec140 Subject: [P2PSIP] [CFP] P2P-NVE 2010 (Deadline: August 20, 2010) 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, 17 Jul 2010 05:40:52 -0000 --00c09f89939bda9601048b8ec140 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Colleagues, You are invited to submit papers to =93The 4th International Workshop on Peer-to-Peer Networked Virtual Environments (P2P-NVE 2010)=94 in conjunctio= n with =93The 16th International Conference on Parallel and Distributed Syste= ms (ICPADS 2010),=94 held on December 8-10, 2010 in Shanghai, China. Please submit your papers soon and help distribute the CFP attached below. Best regards, Jehn-Ruey Jiang Program Chair of P2P-NVE 2010 Department of Computer Science and Information Engineering National Central University Jhongli City, Taoyuan, 32001, Taiwan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Call for Papers The 4th International Workshop on Peer-to-Peer Networked Virtual Environments (P2P-NVE 2010) in conjunction with The 16th International Conference on Parallel and Distributed Systems (ICPADS 2010) December 8 -10, 2010 Shanghai, China http://acnlab.csie.ncu.edu.tw/P2PNVE2010/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D PURPOSE AND SCOPE A networked virtual environment (NVE), also known as a distributed virtual environment (DVE) or collaborative virtual environment (CVE), is a computer-generated virtual world where multiple users can assume virtual representatives (or avatars) to concurrently interact with each other via networked links. Examples of NVEs include early DARPA SIMNET and DIS system= s as well as currently booming Massively Multiplayer Online Games (MMOGs). Some recent studies propose using P2P architectures to increase NVE scalability and to reduce NVE management and deployment costs. Typical examples of such studies are P2P voice chatting, P2P 3D streaming, P2P game state management, and so on. In spite of the success of the studies, we nee= d more studies about state consistency control, persistent data storage, multimedia data dissemination, cheat-prevention, topology mismatching, and virtual world interoperability to construct NVEs of better performance. The 1st, 2nd and 3rd International Workshop on Peer-to-Peer Networked Virtual Environments were held in conjunction with the 13th, 14th and 15th International Conference on Parallel and Distributed Systems in 2007, 2008 and 2009, respectively. To adhere to the theme of P2P-NVE workshops, the theme of P2P-NVE 2010 is to solicit original and previously unpublished new ideas on general P2P schemes as well as on the design and realization of P2= P NVEs. The workshop aims to facilitate discussions and idea exchanges by bot= h academics and practitioners. Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of relevance, originality, contribution, correctness, and presentation. Topics of interest include, but are not limited to: - P2P systems and infrastructures - Applications of P2P systems - Performance evaluation of P2P systems - Trust and security issues in P2P systems - Network support for P2P systems - Fault tolerance in P2P systems - Data structures for P2P systems - Efficient P2P resource lookup and sharing - Distributed Hash Tables (DHTs) and related issues - Solutions to topology mismatching for P2P overlays - P2P overlays for NVEs - P2P NVE multicast - P2P NVE interoperability - P2P NVE content distribution - P2P NVE 3D streaming - P2P NVE voice communications - P2P NVE architecture designs - P2P NVE prototypes - P2P NVE consistency control - Persistent storage for P2P NVEs - Security and cheat-prevention mechanisms for P2P games - P2P control for mobile NVEs - P2P NVE applications on mobile devices IMPORTANT DATES Submission: August 20, 2010 Notification: September 15, 2010 Camera ready: October 1, 2010 PAPER SUBMISSION Authors are invited to submit an electronic version of original, unpublishe= d manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in PDF format in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of originality, contribution, correctness, and presentation. --00c09f89939bda9601048b8ec140 Content-Type: text/html; charset=Big5 Content-Transfer-Encoding: quoted-printable

Dear Colleagues,

You are invited to submit = papers to “The 4th International Workshop on Peer-to-Peer Networked V= irtual Environments (P2P-NVE 2010)” in conjunction with “The 16= th International Conference on Parallel and Distributed Systems (ICPADS 201= 0),” held on December 8-10, 2010 in Shanghai, China. Please submit yo= ur papers soon and help distribute the CFP attached below.

Best regards,

Jehn-Ruey Jiang

Pro= gram Chair of P2P-NVE 2010

Department of Computer Science and Inf= ormation Engineering

National Central University

Jhongl= i City, Taoyuan, 32001, Taiwan

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Call for Papers

The 4th International Workshop on Peer-to-Peer Netw= orked Virtual Environments (P2P-NVE 2010)

in conjunction with

The 16th International Conference on Par= allel and Distributed Systems (ICPADS 2010)

December 8 -10, 2010<= /div>

Shanghai, China

http://acnlab.csie.ncu.edu.tw/P2PNVE2010/

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

PURPOSE AND SCOPE

A networked virtual environment (NVE), also known as a distribut= ed virtual environment (DVE) or collaborative virtual environment (CVE), is= a computer-generated virtual world where multiple users can assume virtual= representatives (or avatars) to concurrently interact with each other via = networked links. Examples of NVEs include early DARPA SIMNET and DIS system= s as well as currently booming Massively Multiplayer Online Games (MMOGs). = Some recent studies propose using P2P architectures to increase NVE scalabi= lity and to reduce NVE management and deployment costs. Typical examples of= such studies are P2P voice chatting, P2P 3D streaming, P2P game state mana= gement, and so on. In spite of the success of the studies, we need more stu= dies about state consistency control, persistent data storage, multimedia d= ata dissemination, cheat-prevention, topology mismatching, and virtual worl= d interoperability to construct NVEs of better performance.

The 1st, 2nd and 3rd International Workshop on Peer-t= o-Peer Networked Virtual Environments were held in conjunction with the 13t= h, 14th and 15th International Conference on Parallel and Distributed Syste= ms in 2007, 2008 and 2009, respectively. To adhere to the theme of P2P-NVE = workshops, the theme of P2P-NVE 2010 is to solicit original and previously = unpublished new ideas on general P2P schemes as well as on the design and r= ealization of P2P NVEs. The workshop aims to facilitate discussions and ide= a exchanges by both academics and practitioners. Authors are invited to sub= mit an electronic version of original, unpublished manuscripts, not to exce= ed 8 double-columned, single-spaced pages, to the workshop. Submitted paper= s should be in accordance with IEEE Computer Society guidelines, and will b= e refereed by reviewers in terms of relevance, originality, contribution, c= orrectness, and presentation.

Topics of interest include, but are not limited to:

- P2P systems and infrastructures

- Applications of P2P systems

- Performance evalu= ation of P2P systems

- Trust and security issues in P2P systems

- N= etwork support for P2P systems

- Fault tolerance in P2P sy= stems

- Data structures for P2P systems

- = Efficient P2P resource lookup and sharing

- Distributed Hash Tables (DHTs) and related issues

-= Solutions to topology mismatching for P2P overlays

- &nbs= p; P2P overlays for NVEs

- P2P NVE multicast

- &= nbsp; P2P NVE interoperability

- P2P NVE content distribution

- P2P NVE 3D st= reaming

- P2P NVE voice communications

- = P2P NVE architecture designs

- P2P NVE prototypes

- P2P NVE consistency control

- Persistent storage for P2P NVEs

- Security a= nd cheat-prevention mechanisms for P2P games

- P2P control= for mobile NVEs

- P2P NVE applications on mobile devices<= /div>

IMPORTANT DATES

Submission: August 20, 2010

Notification: &nbs= p; September 15, 2010

Camera ready: October 1, 2010=

=A1@

PAPER SUBMISSION

Authors are invited to submit a= n electronic version of original, unpublished manuscripts, not to exceed 8 = double-columned, single-spaced pages, to the workshop. Submitted papers sho= uld be in PDF format in accordance with IEEE Computer Society guidelines, a= nd will be refereed by reviewers in terms of originality, contribution, cor= rectness, and presentation.

--00c09f89939bda9601048b8ec140-- From gonzalo.camarillo@ericsson.com Mon Jul 19 05:12: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 0CE273A68F9 for ; Mon, 19 Jul 2010 05:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.751 X-Spam-Level: X-Spam-Status: No, score=-105.751 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aEAxtqVS9vZ for ; Mon, 19 Jul 2010 05:12:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B50A43A6AFC for ; Mon, 19 Jul 2010 05:12:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-86-4c444131de66 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 22.60.10125.131444C4; Mon, 19 Jul 2010 14:12:33 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 14:12:32 +0200 Received: from [131.160.126.163] ([131.160.126.163]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 14:12:33 +0200 Message-ID: <4C44412B.9050807@ericsson.com> Date: Mon, 19 Jul 2010 15:12:27 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2010 12:12:33.0285 (UTC) FILETIME=[AAD54B50:01CB273B] X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] Fwd: How to transport BFCP in the presence of NATs 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, 19 Jul 2010 12:12:23 -0000 Hi, I have requested feedback on the BFCP over UDP issue to the transport community (see email below). The input we receive may also be relevant to RELOAD. Please, follow the discussions on the TSV area mailing list. Cheers, Gonzalo -------- Original Message -------- Subject: How to transport BFCP in the presence of NATs Date: Mon, 19 Jul 2010 14:00:37 +0200 From: Gonzalo Camarillo To: tsv-area@ietf.org Folks, BFCP (Binary Floor Control Protocol), defined in RFC 4582, runs between a client and a floor control server. Generally, the floor control server has a public IP address. The client establishes a TCP connection towards the floor control server so that, even if the client is behind a NAT, everything works. However, in some existing deployment scenarios the floor control server functionality is implemented in an endpoint, which may be behind a NAT. A typical session between two endpoints in these scenarios consist of a BFCP connection and one or more media streams (e.g., audio and video) between them. In this type of scenario, NAT traversal becomes a problem. Existing deployments implement different approaches to address the fact that the floor control server is not directly reachable. One of these approaches consists of transporting BFCP over UDP instead of over TCP (this approach is documented in the draft below). In this way, the endpoints can use ICE to find connectivity between them. https://datatracker.ietf.org/doc/draft-sandbakken-xcon-bfcp-udp/ An alternative approach would be to still use TCP as a transport and use ICE TCP. However, the success rate of ICE TCP is not high enough at this point. Yet another alternative would be to tunnel BFCP over TCP over UDP. The XCON WG is aware of the guidelines given in RFC 5405 but would like to ask the transport community for further guidance on this issue. Note that this is actually a general issue that will affect any protocol for which TCP would be the natural transport but that would need to run between endpoints in NATted environments. RELOAD (draft-ietf-p2psip-base) would be an example of a similar protocol (which currently intends to use ICE TCP). Given that this issue appear to be more general than BFCP and may affect other protocols, we would appreciate to get input on how to proceed. Thanks, Gonzalo From taixuanyueshi@gmail.com Tue Jul 20 02:37: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 3E1453A6452 for ; Tue, 20 Jul 2010 02:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.452 X-Spam-Level: ** X-Spam-Status: No, score=2.452 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR5+Tz+zApOB for ; Tue, 20 Jul 2010 02:37:06 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id F09023A6C5E for ; Tue, 20 Jul 2010 02:37:05 -0700 (PDT) Received: by iwn38 with SMTP id 38so6183262iwn.31 for ; Tue, 20 Jul 2010 02:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=vfVWFbVFGwyEhW/ng4Yj5o9YwSyRxWZVvRm/REE6n48=; b=csM5cyzkzTyNFzii4cx4cD/iW4UoPiB7pQIIOBWlJAGCS3w6G8BijPe7NRw+OpJxP5 PIjBvz/ODGm/+SD96ksRq5FuU1omTH9AsIX4DTcAO38rNgaawg3q1iy1BdyTnxTRSII3 FUe1+0+IyicOi0BD7GTWQB8YqSA//4ODS+7uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=Ugf/jayMsM9Qe3djmnNJw4TP6nZO+cxkYdOGYCW/9GoWPkYU5x4NZFHU9Se4Q6mTUg RfPRUnKtTR/avm52RPYOreoNNp3sorziLXvOKPv+tWjexteZBl3npb3jROpCtF69qZlu +eB/Pu/wD+5SZjEmWOhJwPyT6FC6Pft8yb9a8= Received: by 10.231.149.12 with SMTP id r12mr7327344ibv.57.1279618640526; Tue, 20 Jul 2010 02:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.60.4 with HTTP; Tue, 20 Jul 2010 02:36:58 -0700 (PDT) From: xuan tai Date: Tue, 20 Jul 2010 17:36:58 +0800 Message-ID: To: p2psip@ietf.org Content-Type: multipart/alternative; boundary=0016e645b942843c88048bce6ee4 Subject: [P2PSIP] A question about "state database" in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 09:37:11 -0000 --0016e645b942843c88048bce6ee4 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Everyone: I have a question when I was reading the draft about RELOAD named =A1=B0* draft-ietf-p2psip-base-08*", and welcome everybody to join me to discuss th= e question. In 5.1.2, it mentions that " Any intermediate peer which forwards a RELOAD message MUST arrange that if it receives a response to that message the response can be routed back through the set of nodes through which the request passed. This may be arranged in one of two ways: o The peer MAY add an entry to the via list in the forwarding header that will enable it to determine the correct node. o The peer MAY keep per-transaction state which will allow it to determine the correct node. ...... " The first question is: What scenario the second method is used for? What the "per-transaction" exactly means? The second question is: As for the example explaining the second method, it mentions an equipment named "state database" which can store the transaction ID and Node ID used for the forwarding of response message. But the draft has not defined such equipment before, so I can't understand it very much, for example, is it a centralized equipment in network? Or a functional entity which can be distributed deployed and ensuring every node can share the same information timely? Thanks a lot. --=20 Regards, =B1=B1=BE=A9=D3=CA=B5=E7=B4=F3=D1=A7 / Beijing University of Posts and Tele= communications (BUPT) =CC=A8=E8=AF / Tai Xuan e-mail: taixuanyueshi@gmail.com mobile:+86135-8176-2082 --0016e645b942843c88048bce6ee4 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Dear Everyone:
I have a question when I was reading the draft = about RELOAD named “draft-ietf-p2psip-base-08&qu= ot;, and welcome everybody to join me to discuss the question.

In 5.1.2, it me= ntions that

<= span> Any intermediate peer which forwards a RELOAD message MUS= T arrange that if it receives a re= sponse to that message the response can be routed back through the set of nodes through which the request passed. This may b= e arranged in one of two ways:

<= span> o The peer MAY add an entry to = the via list in the forwarding header

<= span> that will enable it to determine= the correct node.

<= span> o The peer MAY keep per-transac= tion state which will allow it to

<= span> determine the correct node.

......

The firs= t question is:

What scenario the second method is used for? What the "= ;per-transaction" exactly means?

The seco= nd question is:

As for the example explaining the second method, it me= ntions an equipment named "state database" which can store t= he transaction ID and Node ID used for the forwarding of response message. = But the draft has not defined such equipment before, so I can't underst= and it very much, for example, is it a centralized equipment in network? Or= a functional entity which can be distributed deployed and ensuring&nb= sp;every node can share the same information timely?

Thanks a lot.

-- =
Regards,

=B1=B1=BE=A9=D3=CA=B5=E7=B4=F3=D1=A7 / Beijing University of Posts and = Telecommunications (BUPT)
=CC=A8=E8=AF / Tai Xuan
e-mail: taixuanyueshi@gmail.com
mobile:+86135-8176-2082

--0016e645b942843c88048bce6ee4-- From julian@orchidseed.org Tue Jul 20 21:23: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 A06733A69D2 for ; Tue, 20 Jul 2010 21:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkaDAMWdxJA3 for ; Tue, 20 Jul 2010 21:23:49 -0700 (PDT) Received: from n15.c05.mtsvc.net (n15.c05.mtsvc.net [70.32.68.15]) by core3.amsl.com (Postfix) with ESMTP id 657D33A6B4A for ; Tue, 20 Jul 2010 21:23:34 -0700 (PDT) Received: from 71-22-238-54.gar.clearwire-wmx.net ([71.22.238.54]:46501 helo=[172.16.1.232]) by n15.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1ObQqS-0003qo-Ik; Tue, 20 Jul 2010 21:23:50 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1-731311585 From: jc In-Reply-To: Date: Wed, 21 Jul 2010 00:23:42 -0400 Message-Id: References: To: xuan tai X-Mailer: Apple Mail (2.1081) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip@ietf.org Subject: Re: [P2PSIP] A question about "state database" in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 04:23:51 -0000 --Apple-Mail-1-731311585 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 On Jul 20, 2010, at 5:36 AM, xuan tai wrote: > Dear Everyone: > I have a question when I was reading the draft about RELOAD named = =A1=B0draft-ietf-p2psip-base-08", and welcome everybody to join me to = discuss the question. > In 5.1.2, it mentions that > " > Any intermediate peer which forwards a RELOAD message MUST arrange = that if it receives a response to that message the response can be = routed back through the set of nodes through which the request passed. = This may be arranged in one of two ways: > o The peer MAY add an entry to the via list in the forwarding = header > that will enable it to determine the correct node. > o The peer MAY keep per-transaction state which will allow it to > determine the correct node. > ...... > " > =20 > The first question is: > What scenario the second method is used for? What the = "per-transaction" exactly means? This means that an intermediate node will "hold state" information on = the message until no longer necessary. > The second question is: > As for the example explaining the second method, it mentions an = equipment named "state database" which can store the transaction ID and = Node ID used for the forwarding of response message. But the draft has = not defined such equipment before, so I can't understand it very much, = for example, is it a centralized equipment in network? Or a functional = entity which can be distributed deployed and ensuring every node can = share the same information timely? The "state database can be anything. It could be as simple as an = std::vector where node_state is some class that holds state = information. > =20 > Thanks a lot. >=20 > --=20 > Regards, >=20 > =B1=B1=BE=A9=D3=CA=B5=E7=B4=F3=D1=A7 / Beijing University of Posts and = Telecommunications (BUPT) > =CC=A8=E8=AF / Tai Xuan > e-mail: taixuanyueshi@gmail.com > mobile:+86135-8176-2082 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1-731311585 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312

Dear = Everyone:
I have a question when I was reading the draft = about RELOAD named =A1=B0draft-ietf-p2psip-base-08", = and welcome everybody to join me to discuss the question.

In 5.1.2, it = mentions that

"
Any = intermediate peer which forwards a RELOAD message MUST = arrange that if it receives a = response to that message the response can be routed back through the set of nodes = through which the request = passed. This may be arranged in one of two = ways:

   o The peer = MAY add an entry to the via list in the forwarding = header
      that will = enable it to determine the correct node.
   = o The peer MAY keep per-transaction state = which will allow it to
      determine the = correct node.
......
"

The first = question is:
What scenario the second method = is used for? What the "per-transaction" = exactly means?

<= div>This means that an intermediate node will "hold state" information = on the message until no longer necessary.

The second question is:
As for the example explaining the second method, = it mentions an equipment named "state database" which can store the = transaction ID and Node ID used for the forwarding of response message. = But the draft has not defined such equipment before, so I can't = understand it very much, for example, is it a centralized equipment in = network? Or a functional entity which can be distributed = deployed and ensuring every node can share the same = information timely? =

The "state database = can be anything. It could be as simple as an = std::vector<node_state> where node_state is some class that holds = state information.

Thanks a = lot.

--
Regards,

=B1=B1=BE=A9=D3=CA=B5=E7=B4=F3=D1=A7 / Beijing University of Posts = and Telecommunications (BUPT)
=CC=A8=E8=AF / Tai Xuan
e-mail: taixuanyueshi@gmail.com
mobile:+86135-8176-2082
_______________________________________________
P2PSIP mailing = list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail-1-731311585-- From julian@orchidseed.org Tue Jul 20 21:24:46 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 0CCF13A69D2 for ; Tue, 20 Jul 2010 21:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=1.226, 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 x0U04ZvrSjTF for ; Tue, 20 Jul 2010 21:24:45 -0700 (PDT) Received: from n20.c05.mtsvc.net (n20.c05.mtsvc.net [70.32.68.20]) by core3.amsl.com (Postfix) with ESMTP id 5944B3A684E for ; Tue, 20 Jul 2010 21:24:45 -0700 (PDT) Received: from 71-22-238-54.gar.clearwire-wmx.net ([71.22.238.54]:46935 helo=[172.16.1.232]) by n20.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1ObQrb-0001Jc-Uj for p2psip@ietf.org; Tue, 20 Jul 2010 21:25:01 -0700 From: jc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 21 Jul 2010 00:24:55 -0400 Message-Id: <4F2A13F1-1DF9-4BB1-B08B-0021D2D86C0E@orchidseed.org> To: P2PSIP Mailing List Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] Typo in 5.1.2. Other 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: Wed, 21 Jul 2010 04:24:46 -0000 I MAY either be a compressed version of the... should be: It MAY either be a compressed version of the... From fluffy@cisco.com Wed Jul 21 09:54: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 559733A684A for ; Wed, 21 Jul 2010 09:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.472 X-Spam-Level: X-Spam-Status: No, score=-110.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 RIR9gEibJgff for ; Wed, 21 Jul 2010 09:54:49 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 550643A6784 for ; Wed, 21 Jul 2010 09:54:49 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMvCRkyrR7Hu/2dsb2JhbACfcXGmYpsIhTIEhACEWQ Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 21 Jul 2010 16:55:05 +0000 Received: from sjc-vpn6-1860.cisco.com (sjc-vpn6-1860.cisco.com [10.21.127.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6LGt51S000695; Wed, 21 Jul 2010 16:55:05 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <20100517121401.61e8c06078a3b23a733c71e914c0b9df.33ee0b709a.wbe@email.secureserver.net> Date: Wed, 21 Jul 2010 09:55:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100517121401.61e8c06078a3b23a733c71e914c0b9df.33ee0b709a.wbe@email.secureserver.net> To: Michael Chen X-Mailer: Apple Mail (2.1081) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] No ICE Attach offer/answer 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, 21 Jul 2010 16:54:50 -0000 Good point and bringing this up in the slides for the meeting. Will get = more out to the list soon. On May 17, 2010, at 12:14 , Michael Chen wrote: > Hi, >=20 > In the current base-08 draft, section 5.5.1.1 has the following > definition: >=20 > overlay_link > corresponds to the OverlayLink production, Overlay Link protocols > used with No ICE MUST specify "no ICE" in their description. >=20 > What is "description"? My suggestion is that this sentence need NOT to > single out no ICE. However, if one insists, this will be a good > revision: >=20 > overlay_link > corresponds to the OverlayLink production, Overlay Link protocols > used with No ICE MUST specify DLTS-UDP-SR-NO-ICE(3) or > TLS-TCP-FH-NO-ICE(4). >=20 > I have a related problem. The last sentence of the "overlay_link" > definition says: >=20 > overlay_link > ... > A single AttachReqAns MUST NOT include both candidates whose > OverlayLink protocols use ICE (the default) and candidates that > specify "no ICE". >=20 > Section 5.5.1.11 says, >=20 > No-ICE is selected when either side has provided "no ICE" Overlay > Link candidates. >=20 > Peers that support ICE can also easily support No-ICE, but the above = two > requirements have these implications: >=20 > 1. In most cases, when peer A wants to Attach to peer X, peer A MUST > decide whether to send an ICE or No-ICE while knowing nothing about X > beyond its NodeId. It seems to me A has no choice but to send ICE > attach. >=20 > 2. When connecting to a bootstrap node or any nodes with known public > IP, there is no need to send the Attach message. Just do D/TLS = directly > to the nodes' IP and port number. >=20 > Then what is the use case for a No-ICE Attach? >=20 > Thanks >=20 > --Michael >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jul 21 09:59: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 6C8AB3A6784 for ; Wed, 21 Jul 2010 09:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.476 X-Spam-Level: X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 tRI8fphModBT for ; Wed, 21 Jul 2010 09:59:36 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6F9573A67C3 for ; Wed, 21 Jul 2010 09:59:36 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPfDRkyrR7Hu/2dsb2JhbACfcXGmX5sIhTIEhACEWQ Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 21 Jul 2010 16:59:53 +0000 Received: from sjc-vpn6-1860.cisco.com (sjc-vpn6-1860.cisco.com [10.21.127.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6LGxqTa003281; Wed, 21 Jul 2010 16:59:52 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F2A13F1-1DF9-4BB1-B08B-0021D2D86C0E@orchidseed.org> Date: Wed, 21 Jul 2010 09:59:52 -0700 Content-Transfer-Encoding: 7bit Message-Id: <1C7ED6F0-80F8-4666-A619-FA194C30D923@cisco.com> References: <4F2A13F1-1DF9-4BB1-B08B-0021D2D86C0E@orchidseed.org> To: jc X-Mailer: Apple Mail (2.1081) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Typo in 5.1.2. Other 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: Wed, 21 Jul 2010 16:59:37 -0000 thanks - fixed in next version On Jul 20, 2010, at 21:24 , jc wrote: > I MAY either be a compressed version of the... > > should be: > > > It MAY either be a compressed version of the... > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From bbl@lowekamp.net Wed Jul 21 12:32:33 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 0A6693A6B31 for ; Wed, 21 Jul 2010 12:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bvb5uRCmKXY for ; Wed, 21 Jul 2010 12:32:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 6D5BF3A6B2C for ; Wed, 21 Jul 2010 12:31:35 -0700 (PDT) Received: by gwj19 with SMTP id 19so4205753gwj.31 for ; Wed, 21 Jul 2010 12:31:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.117.11 with SMTP id p11mr2603793ybc.316.1279740708794; Wed, 21 Jul 2010 12:31:48 -0700 (PDT) Received: by 10.231.141.65 with HTTP; Wed, 21 Jul 2010 12:31:42 -0700 (PDT) In-Reply-To: References: <20100415160619.61e8c06078a3b23a733c71e914c0b9df.46cc2c2ad7.wbe@email.secureserver.net> <4BC8FF87.5050204@idssoftware.com> <7D097272-0561-46E7-A1CC-1EDDAD5535D6@orchidseed.org> <4BCC8B15.5080507@idssoftware.com> <4BCCAE4D.7070607@idssoftware.com> <9B7A1C69-5956-472D-A564-3AD7FCA0E113@orchidseed.org> Date: Wed, 21 Jul 2010 12:31:42 -0700 Message-ID: From: Bruce Lowekamp To: jc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Reload bcast and mcast discovery 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, 21 Jul 2010 19:32:33 -0000 After further thought, I think this is going to be addressed naturally by what tsvwg is doing in specifying proper tunneled protocols and ICE negotiation for them. I think it would be better to keep the base simple protocol as simple as possible, rather than adding the complexity of delayed ACK to it. Bruce On Mon, Apr 19, 2010 at 2:40 PM, Bruce Lowekamp wrote: > I'm a bit hesitant to support a decision based on message length, > though I can't think of a reason it wouldn't work, so I'm not opposed > to it offhand, either. =C2=A0However, this is still a draft, and if a > change is needed to the base protocol to make it work well, we should > do that. > > Bruce > > > On Mon, Apr 19, 2010 at 12:59 PM, jc wrote: >> Right. Assuming the ack frame remains the same size this is the best >> solution short of base protocol change to support this. >> >> Sent from my iPhone >> >> On Apr 19, 2010, at 3:26 PM, Michael Chen wro= te: >> >>> Julian, >>> >>> Yes (with correction): "guess if there is an DATA frame based on the UD= P >>> packet size of an ACK frame". >>> >>> If you want further confirmation, verify that the 10th byte (just beyon= d >>> the ACK frame) in the packet is DATA(128). >>> >>> --Michael >>> >>> >>> jc wrote: >>>> >>>> Michael, >>>> >>>> So your saying we should guess if there is an ack frame based on packe= t >>>> size? >>>> >>>> Julian >>>> >>>> On Apr 19, 2010, at 12:55 PM, Michael Chen wrote: >>>> >>>> >>>>> Julian, >>>>> >>>>> There is no different in deserializing this and the Reload message >>>>> itself, both are full of variable length and nested structures. It's >>>>> actually a lot simpler, >>>>> >>>>> 1. Receive a UDP packet (after DTLS decryption) that starts with ACK >>>>> (129) but the packet is size greater than 9 (size of ACK frame). >>>>> >>>>> 2. Consume the first 9 bytes and handles the ACK frame. >>>>> >>>>> 3. Discard the first 9 bytes, and handles the remaining PDU as a norm= al >>>>> DATA frame (deserialize). >>>>> >>>>> --Michael >>>>> >>>>> jc wrote: >>>>> >>>>>> Yes but that's darn ugly and would be a deserialization nightmare. := -) >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Apr 16, 2010, at 8:23 PM, Michael Chen >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Julian, >>>>>>> >>>>>>> UDP transport requires the reload fragment to fit in a single MTU s= ize >>>>>>> packet after DTLS encryption. In this case, after DTLS decryption, = you get a >>>>>>> PDU with known size. Each element in this PDU has their own account= of their >>>>>>> size. Therefore, >>>>>>> >>>>>>> sizeof(ACK_frame) =3D=3D 5; >>>>>>> sizeof(DATA_frame) =3D=3D >>>>>>> sizeof(RELOAD_header) + >>>>>>> sizeof(RELOAD_message) + >>>>>>> sizeof(Security_block); >>>>>>> >>>>>>> sizeof(PDU) =3D=3D sizeof(ACK_frame) + sizeof(DATA_frame) >>>>>>> >>>>>>> If the message is fragmented, then this only applies to the first >>>>>>> fragment, which is also inside the boundary of DATA_frame (the 24-b= it frame >>>>>>> size). >>>>>>> >>>>>>> Am I right? >>>>>>> >>>>>>> --Michael >>>>>>> >>>>>>> >>>>>>> jc wrote: >>>>>>> >>>>>>>> On Apr 15, 2010, at 7:06 PM, Michael Chen wrote: >>>>>>>> >>>>>>>> >>>>>>>>> -------- Original Message -------- >>>>>>>>> Subject: Re: Reload bcast and mcast discovery >>>>>>>>> From: jc > >>>>>>>>> Date: Thu, April 15, 2010 2:02 pm >>>>>>>>> To: Michael Chen >>>>>>>> > >>>>>>>>> >>>>>>>>> Right, sorry I keep thinking in the context of ALL messages. Ping= s >>>>>>>>> will work ok using this method but currently no other PDU's becau= se of >>>>>>>>> possible need to fragment. In order to support this changes to th= e base >>>>>>>>> draft would need to occur allowing messages without a framing hea= der unless >>>>>>>>> you have a way around this? >>>>>>>>> >>>>>>>>> >>>>>>>>> I guess it is unlikely the group will accept frameless message at >>>>>>>>> this point, which is why I am hesitated to do it. However, I do h= ave an >>>>>>>>> alternative. >>>>>>>>> >>>>>>>>> >>>>>>>>> What if the base draft allows sending the ACK frame with the >>>>>>>>> response message in the same UDP packet? The response PDU would l= ook like >>>>>>>>> this: >>>>>>>>> >>>>>>>>> >>>>>>>>> [ACK_frame] >>>>>>>>> >>>>>>>>> [DATA_frame] >>>>>>>>> >>>>>>>>> [RELO_header] >>>>>>>>> >>>>>>>>> [RELO_message] >>>>>>>>> >>>>>>>>> [Security block] >>>>>>>>> >>>>>>>>> >>>>>>>>> This keeps the compatibility of framing header and Simple >>>>>>>>> Reliability for UDP (it's the same logical order of PDUs in TCP).= This usage >>>>>>>>> can be extended to include regular link layer responses when the = response is >>>>>>>>> single hopped like bootstrap node discovery. What do you think? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I think that "piggybacking" ack frames to response's is much neede= d >>>>>>>> and I welcome this change. This would solve any ack related headac= hes that I >>>>>>>> know currently exist and as you mention will reduce traffic by 50%= under >>>>>>>> certain conditions. >>>>>>>> >>>>>>>> >>>>>>>>> --Michael >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>> >>>> >>>> >>>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > From fluffy@cisco.com Thu Jul 22 18:42:32 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 391553A6863 for ; Thu, 22 Jul 2010 18:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 aQpnGNPNtduT for ; Thu, 22 Jul 2010 18:42:31 -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 5B4DC3A65A5 for ; Thu, 22 Jul 2010 18:42:31 -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: AvsEAEeQSEyrR7Hu/2dsb2JhbACfZHGeNIgumweFNgSEAIRZ Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 23 Jul 2010 01:42:49 +0000 Received: from sjc-vpn5-140.cisco.com (sjc-vpn5-140.cisco.com [10.21.88.140]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6N1gnEX002936 for ; Fri, 23 Jul 2010 01:42:49 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 18:42:48 -0700 Message-Id: <351B0CF3-2C6E-4632-AC01-1E97434077B6@cisco.com> To: P2PSIP WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [P2PSIP] WG Meeting Preview 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, 23 Jul 2010 01:42:32 -0000 We've scheduled a bunch of time in Maastricht to talk about RELOAD Open = Issues. This mail contains a preview of the issues we think still need = some resolution: 1. Overlay Link Protocols On May 17, 2010 Michael Chen raised a good point: 1. In most cases, when peer A wants to Attach to peer X, peer A MUST decide whether to send an ICE or No-ICE while knowing nothing about X beyond its NodeId. It seems to me A has no choice but to send ICE attach. =20 2. When connecting to a bootstrap node or any nodes with known public IP, there is no need to send the Attach message. Just do D/TLS = directly to the nodes' IP and port number. Then what is the use case for a No-ICE Attach? However, we have had requests from people who want to support non-ICE environments.=20 Proposed resolution: The overlay needs to specify if ICE used or not. This is consistent with how we had intended for it to be, but the draft is probably inconsistent. If people know of places where there are such errors, please point them out and we'll fix them. 2. Direct Return Response In some cases this requires the ability to modify forwarding headers. Offline discussion with Roni leads us to believe this can be done with current Forwarding header with no change to draft. We will reconfirm = with Roni that this this issue is closed. Will update draft to fix wording to clarify that intermediate peers can modify forwarding options. 3. Overlay Algorithm There was some discussion about when the finger table is needed or not = needed when doing an ATTACH. We propose to add a flag to the attach = request that indicates if the finger table should be transferred. Do we have consensus for this change? 4. Transport Security We still haven't resolved the question of how to handle security. Proposal: Per our proposal last IETF, we propose have TLS as the basic mechanism, but other mechanisms can in principle be defined. We will add a field to the configuration that specifies the security mechanism of the overlay. The only one defined in this document is TLS. Any standard track document that defines new ones MUST provide at minimum: (1) endpoint authentication (2) message integrity, and (3) confidentiality. 5. Peer-ID Length The current document specifies a fixed 128-bit peer-ID. Some people have requested a longer ID. Proposal: Stay with the rough consensus from IETF 77 of a variable length (per-overlay) ID with a maximum possible size of 160 bits. From julian@orchidseed.org Fri Jul 23 16:37:04 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 C4A963A67D9 for ; Fri, 23 Jul 2010 16:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.612, 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 5kEsz6pM0xIH for ; Fri, 23 Jul 2010 16:37:03 -0700 (PDT) Received: from n20.c05.mtsvc.net (n20.c05.mtsvc.net [70.32.68.20]) by core3.amsl.com (Postfix) with ESMTP id CE9263A67FB for ; Fri, 23 Jul 2010 16:37:03 -0700 (PDT) Received: from 71-22-238-54.gar.clearwire-wmx.net ([71.22.238.54]:36416 helo=[172.16.1.232]) by n20.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1OcRns-0004dK-Eb for p2psip@ietf.org; Fri, 23 Jul 2010 16:37:22 -0700 From: jc Content-Type: multipart/alternative; boundary=Apple-Mail-3-973329113 Date: Fri, 23 Jul 2010 19:37:19 -0400 Message-Id: To: P2PSIP Mailing List Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] Multicast Bootstrap Issue 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, 23 Jul 2010 23:37:04 -0000 --Apple-Mail-3-973329113 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, Using multicast bootstrap as loosely defined I have uncovered two = problems. 1. If the RELOAD port is used for multicast group subscription then an = implemented stack will give undesirable results at the message handler = level. This is due to multiple sockets bound to the same port using = socket option SO_REUSEADDR. The results are dropped, duplicate or = unwanted messages arriving at incorrect handlers. 2. If the multicast group subscription port is not the RELOAD port the = recipient of the multicast, unicast or anycast request has no way to = tell which port it must contact to send a response. 10.4. Searching for a Bootstrap Node ... The responder node that receives the Ping request SHOULD check that the overlay name is correct and that the requester peer sending the request has appropriate credentials for the overlay before responding to the Ping request even if the response is only an error. If a node uses a non-reload port number for multicast group subscription = the responder doesn't know which port to contact in order to send a = response. It should be considered "unsafe" to assume the RELOAD port = because implementors may use random port allocation or the RELOAD port = may be unavailable. Regards, Julian Cain= --Apple-Mail-3-973329113 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

Using multicast bootstrap as loosely defined I have uncovered = two problems.

1. If the RELOAD port is used = for multicast group subscription then an implemented stack = will give undesirable results at the message handler level. This is due = to multiple sockets bound to the same port using socket option = SO_REUSEADDR. The results are dropped, duplicate or unwanted messages = arriving at incorrect handlers.

2. If = the multicast group subscription port is not the RELOAD port = the recipient of the multicast, unicast or anycast request has no way to = tell which port it must contact to send a = response.

10.4. Searching for a Bootstrap = Node

... The responder node that receives the Ping request SHOULD check that the overlay name is correct and that the requester peer sending the request has appropriate credentials for the overlay before responding to the Ping request even if the response is only an error.

If a node uses a non-reload port number for =
multicast group subscription the responder doesn't know which port to =
contact in order to send a response. It should be considered "unsafe" to =
assume the RELOAD port because implementors may use random port =
allocation or the RELOAD port may be =
unavailable.

R= egards,

Julian Cain

= --Apple-Mail-3-973329113-- From bbl@lowekamp.net Mon Jul 26 07:34:32 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 11D1E3A68DA for ; Mon, 26 Jul 2010 07:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4Fp1iG5gAZi for ; Mon, 26 Jul 2010 07:34:31 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id C340E3A68A0 for ; Mon, 26 Jul 2010 07:34:30 -0700 (PDT) Received: by pxi20 with SMTP id 20so80507pxi.31 for ; Mon, 26 Jul 2010 07:34:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.180.20 with SMTP id c20mr9107156wff.134.1280154891876; Mon, 26 Jul 2010 07:34:51 -0700 (PDT) Received: by 10.231.32.70 with HTTP; Mon, 26 Jul 2010 07:34:51 -0700 (PDT) In-Reply-To: References: <20100517121401.61e8c06078a3b23a733c71e914c0b9df.33ee0b709a.wbe@email.secureserver.net> Date: Mon, 26 Jul 2010 07:34:51 -0700 Message-ID: From: Bruce Lowekamp To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] No ICE Attach offer/answer 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, 26 Jul 2010 14:34:32 -0000 There was an attempt in the previous revision to make ICE and No-ICE interoperate. I think this was a mistake and we should go with what I think the consensus was when we adopted no-ice, which was to either have all nodes on an overlay using ICE or all nodes not using ICE. Bruce On Wed, Jul 21, 2010 at 9:55 AM, Cullen Jennings wrote: > > Good point and bringing this up in the slides for the meeting. Will get m= ore out to the list soon. > > > On May 17, 2010, at 12:14 , Michael Chen wrote: > >> Hi, >> >> In the current base-08 draft, section 5.5.1.1 has the following >> definition: >> >> =C2=A0 overlay_link >> =C2=A0 =C2=A0 =C2=A0corresponds to the OverlayLink production, Overlay L= ink protocols >> =C2=A0 =C2=A0 =C2=A0used with No ICE MUST specify "no ICE" in their desc= ription. >> >> What is "description"? My suggestion is that this sentence need NOT to >> single out no ICE. However, if one insists, this will be a good >> revision: >> >> =C2=A0 overlay_link >> =C2=A0 =C2=A0 =C2=A0corresponds to the OverlayLink production, Overlay L= ink protocols >> =C2=A0 =C2=A0 =C2=A0used with No ICE MUST specify DLTS-UDP-SR-NO-ICE(3) = or >> TLS-TCP-FH-NO-ICE(4). >> >> I have a related problem. The last sentence of the "overlay_link" >> definition says: >> >> =C2=A0 overlay_link >> =C2=A0 =C2=A0 =C2=A0... >> =C2=A0 =C2=A0 =C2=A0A single AttachReqAns MUST NOT include both candidat= es whose >> =C2=A0 =C2=A0 =C2=A0OverlayLink protocols use ICE (the default) and cand= idates that >> =C2=A0 =C2=A0 =C2=A0specify "no ICE". >> >> Section 5.5.1.11 says, >> >> =C2=A0 No-ICE is selected when either side has provided "no ICE" Overlay >> Link candidates. >> >> Peers that support ICE can also easily support No-ICE, but the above two >> requirements have these implications: >> >> 1. In most cases, when peer A wants to Attach to peer X, peer A MUST >> decide whether to send an ICE or No-ICE while knowing nothing about X >> beyond its NodeId. It seems to me A has no choice but to send ICE >> attach. >> >> 2. When connecting to a bootstrap node or any nodes with known public >> IP, there is no need to send the Attach message. Just do D/TLS directly >> to the nodes' IP and port number. >> >> Then what is the use case for a No-ICE Attach? >> >> Thanks >> >> --Michael >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From davidbryan@gmail.com Wed Jul 28 01:43: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 E5EE43A69F7 for