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).=
div>
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.=
p>
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...=
font>
> _______________________________________________
> 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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:=
div>
- 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=
a>
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
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.
......
"
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.commobile:+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