[p2psip] asking about the lifetime of the stored data and refreshing= mechanism

--Michael

-------- Original Message --------
Subject: What is SipRegistrationData.contact_prefs?
From: "Michael Chen" <michaelc@idssoftware.com>
Date: Tue, January 05, 2010 4:59 pm
To: p2psip@ietf.org

Hi,

In the current draft-ietf-p2psip-sip-0= 3, there is no definition for field:

SipReg= istration.SipRegistrationData.contact_prefs

= o If the registration is of type "sip_registration_route", the= n the
contents are an opaque string conta= ining the callee's contact
preferences an= d a destination list for the peer.

What is contact prefer= ences?

Thanks

--M= ichael
=20

From sunchw@gmail.com Thu Jan 7 04:13:52 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C5E3A67E2 for ; Thu, 7 Jan 2010 04:13:51 -0800 (PST) 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 jPyNO1A19t+M for ; Thu, 7 Jan 2010 04:13:50 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 757D13A676A for ; Thu, 7 Jan 2010 04:13:49 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so3689870eye.51 for ; Thu, 07 Jan 2010 04:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PtrVXaVMc6zf7xhuJBbhAYeXskcRtV1dVBS2xe7Y0BM=; b=GWy0GIKXrWt8PhYlmtGKvzT9Vtu6NBXl+KjEUtNfmc1HrNLV/AylzxfjgY7ufiqQc1 acRUKL/9/dK9/+KiZqrwNo9sXCVr5HKa7vWnhR4im8OsbuZOEzCEzjCpgvRGrd3RI7jl vUqPOS/7S+rk+QMSSftl4gIXRTKBJTausIvMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z2SXIrobhdgbtYFScgl8FfO2YRFpdl+kQdF5x4UbR/0EdwGhxQ195MRdmb+aIyOqy7 IKb3t++UlpFgF598km6INEM/EklvpGJxfFUcAbvNYPhqyfgk+rArWJGGeyTYhtcl4HaE uJuMTog1IkTV1uJiimJivvsNR+ntMUVac5arw= MIME-Version: 1.0 Received: by 10.216.85.144 with SMTP id u16mr1336602wee.3.1262866423218; Thu, 07 Jan 2010 04:13:43 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Jan 2010 20:13:43 +0800 Message-ID: From: Sun Chongwei To: peng.yonglin@zte.com.cn Content-Type: multipart/alternative; boundary=0016e6d58b9a8e00f4047c920000 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-06: one question about Probe X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 12:13:52 -0000 --0016e6d58b9a8e00f4047c920000 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable in 5..4.2.5 Probe Probe was introduced. Probe will be used in following conditions. 1) Peer A will send a ProbeReq message to destination peer B when A want to find out the fraction of overlay for which B is responsible. 2) When Peer A want to know the number of resources being stored by B, A send a ProbeReq to B 3) Peer A want to get how long B has been up 2010/1/7 > > Hi, > > I have one question about Probe In base-06, In which scenarios the Probe = be > used? > Some functions are implemented by Ping instead of Probe in base-06, such = as > seaching bootstrap peer, populating routing talbe. So there seem to be no= t > concrete using scenarios of Probe. > > > ************************************************* > =D3=CA =BC=FE=A3=BApeng.yonglin@zte.com.cn > =C4=DA =CF=DF=A3=BA88190 > =CD=E2 =CF=DF=A3=BA025-52878190 > =CA=D6 =BB=FA=A3=BA13776637274 > ************************************************* > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > --=20 Sun Chongwei Mobile LIfe and New Media Lab Beijing University of Posts and Telecommunications --0016e6d58b9a8e00f4047c920000 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

in 5..4.2.5 Probe

Probe was introduced.

Probe will be used in following conditions.

1) Peer A wi= ll send a ProbeReq message to destination peer B when A want to find out th= e fraction of overlay for which B is responsible.

2) When Peer A want to know the number of resources being stored by B,= A send a ProbeReq to B

3) Peer A want to get how long B has = been up

2010/1/7 <= peng.yonglin@zte.com.cn>

Hi,

I have one question about Probe In= base-06, In which scenarios the Probe be used?
Some functions are implemented by = Ping instead of Probe in base-06, such as seaching bootstrap peer, populating routing talbe. So there seem to be not concrete using scenarios of Probe.

*************************************************
=D3=CA =BC=FE=A3=BApeng.yonglin@zte.com.cn
=C4=DA =CF=DF=A3=BA88190
=CD=E2 =CF=DF=A3=BA025-52878190
=CA=D6 =BB=FA=A3=BA13776637274
*************************************************
--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip

--
Sun Chongwei
Mob= ile LIfe and New Media Lab
Beijing University of Posts and Telecommunica= tions
--0016e6d58b9a8e00f4047c920000-- From sunchw@gmail.com Thu Jan 7 04:29: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 7A7F73A67E7 for ; Thu, 7 Jan 2010 04:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy7ZDYhHbMKS for ; Thu, 7 Jan 2010 04:29:45 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id C5A613A67B5 for ; Thu, 7 Jan 2010 04:29:44 -0800 (PST) Received: by ewy6 with SMTP id 6so17573661ewy.29 for ; Thu, 07 Jan 2010 04:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SDn5TixsaniDizyOLIBQUiBRY0NeDIQCYv0SX3XvtOc=; b=lmtIEYyZkjcJ0os2OU48f8ePF1CgC1u79zEJ0N6a+t5StjI0jJAHuEErUWh6907Qgi 0BK6uzizX070FeaO0M32LVPXkAPoJIU6mrDrZzwyabCTQIwFI2PlCTfF3G0eVIdY+1Gi ECM4M1G3rLH8tC/isB5hJz1864KFWsSqDsDcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IbxpB3Kh25MD6x9MrSH6kJk6sSjMjjYZPp8f36noXd8+fwrf7ZMm6KeKr2P7xLIE1+ vlU2VPijxccgJDgQo3Ylvn189me0Afx3PvBtue/VafiZLrKPGUnV19WYW24xOhTB+UXJ aa0Db4fT7z5tjUnm7+/lACM4bY5ah67UjXMzg= MIME-Version: 1.0 Received: by 10.216.86.211 with SMTP id w61mr859087wee.6.1262867378999; Thu, 07 Jan 2010 04:29:38 -0800 (PST) In-Reply-To: <4A956CE47D1066408D5C7EB34368A51105944B8B@S4DE8PSAAQC.mitte.t-com.de> References: <4A956CE47D1066408D5C7EB34368A51105944B8B@S4DE8PSAAQC.mitte.t-com.de> Date: Thu, 7 Jan 2010 20:29:38 +0800 Message-ID: From: Sun Chongwei To: BeckW@telekom.de Content-Type: multipart/alternative; boundary=0016e6d785538613b2047c9239b9 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-06; message flow examples, leaving X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 12:29:46 -0000 --0016e6d785538613b2047c9239b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is NP short for? I can not find its full name in the draft Thank you! 2010/1/6 > Some comments: > > Section 3.5.2 Joining, Leaving, and Maintenance Overview > > Joining is discussed in depth, Leaving and Maintenance seem to be missin= g. > > > Section 11, second message flow -- attach to neighbor peer > > Just before the TLS arrow from JP to NP, there's an extra arrow labelled > 'Attach' to the NP. Why is this necessary? Didn't JP already obtain NP's = ICE > candidates in the preceding Attach exchange shown in the diagram? > > There's little text about leaving an overlay. Section 9 'Chord Algorithm' > discusses it (9.8), but the algorithm- independent sections barely mentio= n > it. > > > > Regards, > > Wolfgang Beck > > > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Wolfgang Beck > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628 2832 (Tel.) > www.telekom.com > > Erleben, was verbindet. > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mat= heis, > Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --=20 Sun Chongwei Mobile LIfe and New Media Lab Beijing University of Posts and Telecommunications --0016e6d785538613b2047c9239b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

What is NP short for? I can not find its full name in the draft

Thank you!

2010/= 1/6 <BeckW@teleko= m.de>

Some comments:

Section 3.5.2 Joining, Leaving, and Maintenance Overview

=A0Joining is discussed in depth, Leaving and Maintenance seem to be missi= ng.

Section 11, second message flow -- attach to neighbor peer

=A0Just before the TLS arrow from JP to NP, there's an extra arrow lab= elled 'Attach' to the NP. Why is this necessary? Didn't JP alre= ady obtain NP's ICE candidates in the preceding Attach exchange shown i= n the diagram?

There's little text about leaving an overlay. Section 9 'Chord Algo= rithm' discusses it (9.8), but the algorithm- independent sections bare= ly mention it.

Regards,

Wolfgang Beck

Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Wolfgang Beck
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 628 2832 (Tel.)
www.telekom.com
Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

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

--
Sun Chongwei
Mobile = LIfe and New Media Lab
Beijing University of Posts and Telecommunication= s
--0016e6d785538613b2047c9239b9-- From peng.yonglin@zte.com.cn Thu Jan 7 17:22:44 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE27C3A692A for ; Thu, 7 Jan 2010 17:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.912 X-Spam-Level: X-Spam-Status: No, score=-93.912 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lrDSNhwTaAV for ; Thu, 7 Jan 2010 17:22:43 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id B48313A6929 for ; Thu, 7 Jan 2010 17:22:42 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111642075036648; Fri, 8 Jan 2010 08:49:41 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.3157735057; Fri, 8 Jan 2010 09:22:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o081MZmM074669; Fri, 8 Jan 2010 09:22:35 +0800 (CST) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: To: Sun Chongwei MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Fri, 8 Jan 2010 09:22:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-08 09:22:33, Serialize complete at 2010-01-08 09:22:33 Content-Type: multipart/alternative; boundary="=_alternative 0007B3E7482576A5_=" X-MAIL: mse2.zte.com.cn o081MZmM074669 Cc: p2psip@ietf.org Subject: [P2PSIP] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1pZXRmLXAycHNpcC1iYXNl?= =?gb2312?b?LTA2OiBvbmUgcXVlc3Rpb24gYWJvdXQgUHJvYmU=?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 01:22:45 -0000 This is a multipart message in MIME format. --=_alternative 0007B3E7482576A5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmsgeW91ISBCdXQgSSB3YW50IGtub3cgaW4gd2hpY2ggc2NlbmFyaW9zIHRoZXNlIGZ1bmN0 aW9ucyBvZiBwcm9iZSBiZSANCnVzZWQuIEZvciBleGFtcGxlLCBXaGVuIGRvZXMgYSBwZWVyIG5l ZWQgdG8gZ2V0IGFub3RoZXIgcGVlcidzIHVwdGltZSBieSANCnByb2JlPyANCkp1c3QgYXMgdGhl IGZ1bmN0aW9uIG9mIHBpbmcgaXMgdGVzdGluZyBjb25uZWN0aXZpdHksIGFuZCBhIHBlZXIgbWF5 IGdldCANCnBlZXJzIG9mIHJvdXRpbmcgdGFibGUgYnkgdGhpcyBmdW5jdGlvbiBvZiBwaW5nIHdo ZW4gaXQgcG9wdWxhdGVzIHJvdXRpbmcgDQp0YWJsZS4gDQoNClRoYW5rcw0KDQoNCg0KDQpTdW4g Q2hvbmd3ZWkgPHN1bmNod0BnbWFpbC5jb20+IA0KMjAxMC0wMS0wNyAyMDoxMw0KDQrK1bz+yMsN CnBlbmcueW9uZ2xpbkB6dGUuY29tLmNuDQqzrcvNDQpwMnBzaXBAaWV0Zi5vcmcNCtb3zOINClJl OiBbUDJQU0lQXSBkcmFmdC1pZXRmLXAycHNpcC1iYXNlLTA2OiBvbmUgcXVlc3Rpb24gYWJvdXQg UHJvYmUNCg0KDQoNCg0KDQoNCmluIDUuLjQuMi41IFByb2JlDQpQcm9iZSB3YXMgaW50cm9kdWNl ZC4NCg0KUHJvYmUgd2lsbCBiZSB1c2VkIGluIGZvbGxvd2luZyBjb25kaXRpb25zLg0KMSkgUGVl ciBBIHdpbGwgc2VuZCBhIFByb2JlUmVxIG1lc3NhZ2UgdG8gZGVzdGluYXRpb24gcGVlciBCIHdo ZW4gQSB3YW50IA0KdG8gZmluZCBvdXQgdGhlIGZyYWN0aW9uIG9mIG92ZXJsYXkgZm9yIHdoaWNo IEIgaXMgcmVzcG9uc2libGUuIA0KMikgV2hlbiBQZWVyIEEgd2FudCB0byBrbm93IHRoZSBudW1i ZXIgb2YgcmVzb3VyY2VzIGJlaW5nIHN0b3JlZCBieSBCLCBBIA0Kc2VuZCBhIFByb2JlUmVxIHRv IEINCjMpIFBlZXIgQSB3YW50IHRvIGdldCBob3cgbG9uZyBCIGhhcyBiZWVuIHVwDQoNCg0KDQoy MDEwLzEvNyA8cGVuZy55b25nbGluQHp0ZS5jb20uY24+DQoNCkhpLCANCg0KSSBoYXZlIG9uZSBx dWVzdGlvbiBhYm91dCBQcm9iZSBJbiBiYXNlLTA2LCBJbiB3aGljaCBzY2VuYXJpb3MgdGhlIFBy b2JlIA0KYmUgdXNlZD8gDQpTb21lIGZ1bmN0aW9ucyBhcmUgaW1wbGVtZW50ZWQgYnkgUGluZyBp bnN0ZWFkIG9mIFByb2JlIGluIGJhc2UtMDYsIHN1Y2ggDQphcyBzZWFjaGluZyBib290c3RyYXAg cGVlciwgcG9wdWxhdGluZyByb3V0aW5nIHRhbGJlLiBTbyB0aGVyZSBzZWVtIHRvIGJlIA0Kbm90 IGNvbmNyZXRlIHVzaW5nIHNjZW5hcmlvcyBvZiBQcm9iZS4gDQoNCg0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K08ogvP6junBlbmcueW9uZ2xpbkB6 dGUuY29tLmNuDQrE2iDP36O6ODgxOTANCs3iIM/fo7owMjUtNTI4NzgxOTANCsrWILv6o7oxMzc3 NjYzNzI3NA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVudGlhbC4g UmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kg YW5kIA0KYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFk ZHJlc3NlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFz ZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwgc2VuZGVy Lg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkg WlRFIEFudGktU3BhbSANCnN5c3RlbS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUDJQU0lQIG1haWxpbmcgbGlzdA0KUDJQU0lQQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KDQoNCg0KDQot LSANClN1biBDaG9uZ3dlaQ0KTW9iaWxlIExJZmUgYW5kIE5ldyBNZWRpYSBMYWINCkJlaWppbmcg VW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zDQoNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24u IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVy bWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8g b3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJl IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNj YW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0007B3E7482576A5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSEgQnV0IEkgd2Fu dCBrbm93IGluIHdoaWNoDQpzY2VuYXJpb3MgdGhlc2UgZnVuY3Rpb25zIG9mIHByb2JlIGJlIHVz ZWQuIEZvciBleGFtcGxlLCBXaGVuIGRvZXMgYSBwZWVyDQpuZWVkIHRvIGdldCBhbm90aGVyIHBl ZXIncyB1cHRpbWUgYnkgcHJvYmU/IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+SnVzdCBhcyB0aGUgZnVuY3Rpb24gb2YgcGluZyBpcyB0ZXN0aW5nDQpjb25uZWN0 aXZpdHksIGFuZCBhIHBlZXIgbWF5IGdldCBwZWVycyBvZiByb3V0aW5nIHRhYmxlIGJ5IHRoaXMg ZnVuY3Rpb24NCm9mIHBpbmcgd2hlbiBpdCBwb3B1bGF0ZXMgcm91dGluZyB0YWJsZS4gJm5ic3A7 PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+U3VuIENob25nd2VpICZsdDtzdW5jaHdAZ21haWwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxw Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTAxLTA3IDIwOjEzPC9mb250Pg0K PHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnBlbmcueW9u Z2xpbkB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5wMnBzaXBAaWV0Zi5vcmc8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlJlOiBbUDJQU0lQXSBkcmFmdC1pZXRmLXAycHNpcC1iYXNlLTA2Og0Kb25l IHF1ZXN0aW9uIGFib3V0IFByb2JlPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmluIDUuLjQuMi41IFByb2JlPC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5Qcm9iZSB3YXMgaW50cm9k dWNlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlBy b2JlIHdpbGwgYmUgdXNlZCBpbiBmb2xsb3dpbmcgY29uZGl0aW9ucy48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjEpIFBlZXIgQSB3aWxsIHNlbmQgYSBQcm9iZVJl cSBtZXNzYWdlDQp0byBkZXN0aW5hdGlvbiBwZWVyIEIgd2hlbiBBIHdhbnQgdG8gZmluZCBvdXQg dGhlIGZyYWN0aW9uIG9mIG92ZXJsYXkgZm9yDQp3aGljaCBCIGlzIHJlc3BvbnNpYmxlLiA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjIpIFdoZW4gUGVlciBBIHdh bnQgdG8ga25vdyB0aGUgbnVtYmVyDQpvZiByZXNvdXJjZXMgYmVpbmcgc3RvcmVkIGJ5IEIsIEEg c2VuZCBhIFByb2JlUmVxIHRvIEI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPjMpIFBlZXIgQSB3YW50IHRvIGdldCBob3cgbG9uZyBCIGhhcw0KYmVlbiB1cDwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ MjAxMC8xLzcgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpwZW5nLnlvbmdsaW5AenRlLmNvbS5j bj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5wZW5nLnlvbmds aW5AenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpI aSwgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkkgaGF2ZSBvbmUgcXVlc3Rpb24gYWJv dXQgUHJvYmUgSW4gYmFzZS0wNiwgSW4gd2hpY2ggc2NlbmFyaW9zIHRoZSBQcm9iZQ0KYmUgdXNl ZD8gPGJyPg0KU29tZSBmdW5jdGlvbnMgYXJlIGltcGxlbWVudGVkIGJ5IFBpbmcgaW5zdGVhZCBv ZiBQcm9iZSBpbiBiYXNlLTA2LCBzdWNoDQphcyBzZWFjaGluZyBib290c3RyYXAgcGVlciwgcG9w dWxhdGluZyByb3V0aW5nIHRhbGJlLiBTbyB0aGVyZSBzZWVtIHRvDQpiZSBub3QgY29uY3JldGUg dXNpbmcgc2NlbmFyaW9zIG9mIFByb2JlLiA8YnI+DQo8YnI+DQo8YnI+DQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0K08ogvP6jujwvZm9udD48 YSBocmVmPW1haWx0bzpwZW5nLnlvbmdsaW5AenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnBlbmcueW9uZ2xpbkB6dGUu Y29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CsTaIM/fo7o4ODE5MDxicj4NCs3iIM/fo7owMjUtNTI4NzgxOTA8YnI+DQrK1iC7+qO6MTM3NzY2 MzcyNzQ8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+PHR0Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCmlzIHNvbGVseSBwcm9wZXJ0eSBv ZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbg0KaXMg Y29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFp bnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQpUaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRl bmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZg0KdGhlIG1lc3NhZ2UuIEFu eSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZp ZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1 c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxicj4NCjwvdHQ+PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClAyUFNJUCBtYWlsaW5nIGxpc3Q8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0K PC91PjwvZm9udD48YSBocmVmPW1haWx0bzpQMlBTSVBAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+UDJQU0lQQGlldGYub3JnPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91 PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJw c2lwIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJp ZiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+ DQpTdW4gQ2hvbmd3ZWk8YnI+DQpNb2JpbGUgTElmZSBhbmQgTmV3IE1lZGlhIExhYjxicj4NCkJl aWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zPC9mb250Pg0K PGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNw O05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlz Jm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4m bmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGln YXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZu YnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3Rv Jm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7Zmls ZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZp ZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJz cDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVz c2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZu YnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNw O3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7 QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNz YWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtz Y2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZu YnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0007B3E7482576A5_=-- From hu.yongsheng@zte.com.cn Thu Jan 7 19:18:04 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5498628C0EA for ; Thu, 7 Jan 2010 19:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjpyDPt3v+DL for ; Thu, 7 Jan 2010 19:18:03 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 8185B3A6916 for ; Thu, 7 Jan 2010 19:18:02 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91102075036648; Fri, 8 Jan 2010 10:53:00 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.3193963500; Fri, 8 Jan 2010 11:17:54 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o083Hv0o069442; Fri, 8 Jan 2010 11:17:57 +0800 (CST) (envelope-from hu.yongsheng@zte.com.cn) In-Reply-To: MIME-Version: 1.0 To: Sensitivity: X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: hu.yongsheng@zte.com.cn Date: Fri, 8 Jan 2010 11:17:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-08 11:17:52, Serialize complete at 2010-01-08 11:17:52 Content-Type: multipart/alternative; boundary="=_alternative 00121BC7482576A5_=" X-MAIL: mse2.zte.com.cn o083Hv0o069442 Cc: BeckW@telekom.de Subject: Re: [P2PSIP] draft-ietf-p2psip-base-06; message flow examples, leaving X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 03:18:04 -0000 This is a multipart message in MIME format. --=_alternative 00121BC7482576A5_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, 1.here NP isn't neighbor peer but next peer,to see section 11, last=20 two line of page 118 "To populate its neighbor table, it needs the successor of AP,=20 NP." 2. I agree that the last Attach request is unwanted. Any other=20 explaintion for it? 3. I think the draft runs short of description about peer leaving=20 flow.=20 Further, there are two type peer leaving scenarioes, gentlest and= =20 abrupt. The seconde one should be considered emphatically. Best Regards! +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ + Hu Yongsheng + + Sys. Arch. ZTE Co. + + MSN:hysnj@hotmail.com +=20 + E-mail:hu.yongsheng@zte.com.cn + + Tel:025-52878532 + + Mobile:13912990713 + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ Some comments: Section 3.5.2 Joining, Leaving, and Maintenance Overview Joining is discussed in depth, Leaving and Maintenance seem to be=20 missing. Section 11, second message flow -- attach to neighbor peer Just before the TLS arrow from JP to NP, there's an extra arrow labelled= =20 'Attach' to the NP. Why is this necessary? Didn't JP already obtain NP's=20 ICE candidates in the preceding Attach exchange shown in the diagram? There's little text about leaving an overlay. Section 9 'Chord Algorithm'= =20 discusses it (9.8), but the algorithm- independent sections barely mention= =20 it. Regards, Wolfgang Beck Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2832 (Tel.) www.telekom.com Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is,=20 Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00121BC7482576A5_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
1.here NP isn't n= eighbor peer but next peer,to see section 11, last two line of page 118
"To populate its neighbor table, it needs the successor of AP, NP."
2. I agree that t= he last Attach request is unwanted. Any other explaintion for it?

3. I think the dr= aft runs short of description about peer leaving flow.
Fur= ther, there are two type peer leaving scenarioes, gentlest and abrupt. The second= e one should be considered emphatically.

Best Regards!
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
+ Hu Yongsheng = ; +
+ Sys. Arch. ZTE Co. +
+ MSN:hysnj@hotmail.com +
+ E-mail:hu.yongsheng@zte.com.cn +
+ Tel:025-52878532 +
+ Mobile:13912990713 +
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

Some comments: Section 3.5.2 Joining, Leaving, and Maintenance Overview Joining is discussed in depth, Leaving and Maintenance seem to be missing. Section 11, second message flow -- attach to neighbor peer Just before the TLS arrow from JP to NP, there's an extra arrow labelled 'Attach' to the NP. Why is this necessary? Didn't JP already obtai= n NP's ICE candidates in the preceding Attach exchange shown in the diagram?<= br> There's little text about leaving an overlay. Section 9 'Chord Algorithm' discusses it (9.8), but the algorithm- independent sections barely mention it. Regards, Wolfgang Beck Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2832 (Tel.) www.telekom.com Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip

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

--=_alternative 00121BC7482576A5_=-- From sunchw@gmail.com Wed Jan 13 00:19:35 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 C233B28C105 for ; Wed, 13 Jan 2010 00:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.971 X-Spam-Level: X-Spam-Status: No, score=0.971 tagged_above=-999 required=5 tests=[AWL=1.480, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWA8R2lptUnJ for ; Wed, 13 Jan 2010 00:19:34 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id EAC6A3A685A for ; Wed, 13 Jan 2010 00:19:33 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so5093914eye.51 for ; Wed, 13 Jan 2010 00:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=k8U9w5VyoKoDXoa6eaPlDzb3ryEpSG3JQFaiCiwAwCA=; b=Ax2weY2KMX/Kd4O88k5yXqAhWCUd1vcAxmaZXeveRDJ94cTzuIDzQR0Eowp9o1H/qP HC+F1GdI3DI5oWEl9CbDLpe/lmF3WBhHn4sLZRENaNDTdX878DCVcDO5SiO1ezkqCcFO 9Lo3zBUP0WwKhSRw5MJMMQIDQPz4FPtJSFvNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VSApAkwMksxIBEaCUEmplzp7s2JfvNay8VU6VD+t/8k4fzEWq/adDPmH8vsDu+WNUm Tkw224CxfE0HE/jnw1p0x2frmzvXdsLnJYnVnSotMx6rmBUcaNUTkNl73z78foZOSeDB C+iqU9tgWHpb5oSbJQ16Xm0DsFCOUlfmo9OG0= MIME-Version: 1.0 Received: by 10.216.89.131 with SMTP id c3mr3710320wef.197.1263370768052; Wed, 13 Jan 2010 00:19:28 -0800 (PST) In-Reply-To: References:

Date: Wed, 13 Jan 2010 16:19:28 +0800 Message-ID: From: Sun Chongwei To: hu.yongsheng@zte.com.cn Content-Type: multipart/alternative; boundary=0016e6d99ccad97213047d076d4b Cc: BeckW@telekom.de, p2psip@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-06; message flow examples, leaving X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 08:19:35 -0000 --0016e6d99ccad97213047d076d4b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable see the comments incline. 2010/1/8 > > Hi, > 1.here NP isn't neighbor peer but next peer,to see section 11, last t= wo > line of page 118 > "To populate its neighbor table, it needs the successor of AP, > NP." NP is the successor of AP, Here NP is also the next peer of JP. Am I right? see the diagram in page 119. there are two peers ,named NNP and PPP separately. The author does not mention these two type peers in the test. Is there anyone can tell me there meaning and fuction? > 2. I agree that the last Attach request is unwanted. Any other > explaintion for it? > > 3. I think the draft runs short of description about peer leaving flo= w. > > Further, there are two type peer leaving scenarioes, gentlest and > abrupt. The seconde one should be considered emphatically. > > Best Regards! > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > + Hu Yongsheng + > + Sys. Arch. ZTE Co. + > + MSN:hysnj@hotmail.com + > + E-mail:hu.yongsheng@zte.com.cn > + > + Tel:025-52878532 + > + Mobile:13912990713 + > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > > Some comments: > > Section 3.5.2 Joining, Leaving, and Maintenance Overview > > Joining is discussed in depth, Leaving and Maintenance seem to be missin= g. > > > Section 11, second message flow -- attach to neighbor peer > > Just before the TLS arrow from JP to NP, there's an extra arrow labelled > 'Attach' to the NP. Why is this necessary? Didn't JP already obtain NP's = ICE > candidates in the preceding Attach exchange shown in the diagram? > > There's little text about leaving an overlay. Section 9 'Chord Algorithm' > discusses it (9.8), but the algorithm- independent sections barely mentio= n > it. > > > > Regards, > > Wolfgang Beck > > > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Wolfgang Beck > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628 2832 (Tel.) > www.telekom.com > > Erleben, was verbindet. > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mat= heis, > Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > --=20 Sun Chongwei Mobile LIfe and New Media Lab Beijing University of Posts and Telecommunications --0016e6d99ccad97213047d076d4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable see the comments incline.

2010/1/8 <hu.yongsheng@zt= e.com.cn>

Hi,
=A0 =A0 1.here NP isn't n= eighbor peer but next peer,to see section 11, last two line of page 118
=A0 =A0 =A0 =A0 "To populate its neighbor table, it needs the successor of AP, NP."=

=A0

NP is the successor of AP, Here NP is also = the next peer of JP. Am I right?

see the diagram i= n page 119. there are two peers ,named NNP and PPP separately.

=A0

=A0The author does not mention these two type peers in t= he test. Is there anyone can tell me there meaning and fuction?

<= br>

=A0 =A0 2. I agree that the last Attach request is unwanted. Any other explaintion for it?

=A0 =A0 3. I think the draft runs short of description about peer leaving flow.
=A0 =A0 =A0 =A0 Further, there are two type peer leaving scenarioes, gentlest and abrupt. The second= e one should be =A0considered =A0emphatically.

Best Regards!
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
+ =A0Hu Yongsheng =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+
+ =A0Sys. Arch. ZTE Co. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+
+ =A0MSN:hysnj= @hotmail.com =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+
+ =A0= E-mail:hu.yongsheng@zte.com.cn =A0 =A0 =A0+
+ =A0Tel:025-52878532 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +
+ =A0Mobile:13912990713 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

Some comments: Section 3.5.2 Joining, Leaving, and Maintenance Overview =A0Joining is discussed in depth, Leaving and Maintenance seem to be missing. Section 11, second message flow -- attach to neighbor peer =A0Just before the TLS arrow from JP to NP, there's an extra arrow labelled 'Attach' to the NP. Why is this necessary? Didn't JP a= lready obtain NP's ICE candidates in the preceding Attach exchange shown in the diagr= am? There's little text about leaving an overlay. Section 9 'Chord Algo= rithm' discusses it (9.8), but the algorithm- independent sections barely mention it. Regards, Wolfgang Beck Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2832 (Tel.) www.telekom.com Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org = https://www.ietf.org/mailman/listinfo/p2psip
=
--------------------------------------------------------
ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0in=
=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organiz=
ation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0na=
med=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=
=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=
=A0to=A0others.
This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confiden=
tial=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0=
or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0recei=
ved=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0of=
=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0t=
hose=A0of=A0the=A0individual=A0sender.
This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by=A0Z=
TE=A0Anti-Spam=A0system.
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip

--
Sun Chongwei
Mob= ile LIfe and New Media Lab
Beijing University of Posts and Telecommunica= tions
--0016e6d99ccad97213047d076d4b-- From fluffy@cisco.com Wed Jan 13 12:00: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 5FE973A6A57 for ; Wed, 13 Jan 2010 12:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, 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 W9PbTV3Mz3Xh for ; Wed, 13 Jan 2010 12:00:21 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7595428C16B for ; Wed, 13 Jan 2010 12:00:18 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA61TUurR7Ht/2dsb2JhbADCS5R7hDAE X-IronPort-AV: E=Sophos;i="4.49,270,1262563200"; d="scan'208";a="232647362" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2010 20:00:16 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0DK0FbG011713; Wed, 13 Jan 2010 20:00:15 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4B3B0450.4050203@ericsson.com> Date: Wed, 13 Jan 2010 13:00:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8DC87081-6638-4395-A701-4EE7B52C554F@cisco.com> References: <4B2F7961.3020303@ericsson.com> <1261486213.5565.16.camel@ari.nomadiclab.com> <4B31CB80.9000204@nomadiclab.com> <4B39BF24.1070307@nomadiclab.com> <4B3B0450.4050203@ericsson.com> To: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= X-Mailer: Apple Mail (2.1077) Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] RELOAD overlay configuration document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 20:00:23 -0000 I don't have strong preferences one way or the other. I do't think there = was any particular reason why the current format was selected. I do = think the DTLS and TLS will be run on the same port.=20 Cullen On Dec 30, 2009, at 12:42 AM, Jouni M=E4enp=E4=E4 wrote: > Hi, >=20 > Ari Keranen wrote: >> But back to the original question: wouldn't you also, considering all >> the points we have discussed, prefer the following format (or >> something similar) for the bootstrap-node element: >>=20 >> >>

192.0.0.1

>> 5678 >> TLS >> >>=20 >> over the original format: >>=20 >> 192.0.0.1:5678 >>=20 >> With the new format you are free to use the same port for both TLS = and >> DTLS, but you are not forced to do so. Also, this makes the element >> much more extensible. >=20 > I like the new format since it is easy to extend. >=20 > Cheers, > Jouni > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Wed Jan 13 12:05:20 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 0EE303A68D2 for ; Wed, 13 Jan 2010 12:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 BCvPMQOo-dFG for ; Wed, 13 Jan 2010 12:05:19 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A62553A6A41 for ; Wed, 13 Jan 2010 12:05:18 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADu2TUurR7Hu/2dsb2JhbADCSZR7hDAE X-IronPort-AV: E=Sophos;i="4.49,270,1262563200"; d="scan'208";a="232649895" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2010 20:05:13 +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 o0DK5C4f007913; Wed, 13 Jan 2010 20:05:12 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 13 Jan 2010 13:05:11 -0700 Content-Transfer-Encoding: 7bit Message-Id: <601A5523-4C90-4E94-93B4-5C6A3135412F@cisco.com> References: <4A956CE47D1066408D5C7EB34368A51105944B8B@S4DE8PSAAQC.mitte.t-com.de> To: Sun Chongwei X-Mailer: Apple Mail (2.1077) Cc: BeckW@telekom.de, p2psip@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-06; message flow examples, leaving X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 20:05:20 -0000 NP = Next Peer NNP i= next next peer JP Joining peer AP admitting peer PP previos peer PPP previos previos peer BP bootstrap peer On Jan 7, 2010, at 5:29 AM, Sun Chongwei wrote: > What is NP short for? I can not find its full name in the draft > From michaelc@idssoftware.com Sat Jan 16 08:51: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 C248D3A6813 for ; Sat, 16 Jan 2010 08:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJHlfGoscT8f for ; Sat, 16 Jan 2010 08:51:04 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 8B24C3A67F7 for ; Sat, 16 Jan 2010 08:51:04 -0800 (PST) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NWBrY-0000zD-H1; Sat, 16 Jan 2010 11:51:00 -0500 Message-ID: <4B51EE87.6060002@idssoftware.com> Date: Sat, 16 Jan 2010 08:51:19 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cullen Jennings , P2PSIP WG References: <20100106205335.61e8c06078a3b23a733c71e914c0b9df.27b3568a6c.wbe@email.secureserver.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940396279310451fb38b0ed6985d194a459350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Subject: Re: [P2PSIP] What is SipRegistrationData.contact_prefs? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 16:51:05 -0000 Cullen, There are some related problems for the sip-03 draft: 1. When multiple destinations are specified in the structure, the draft is not clear how the contact preference for each destination is specified in the single contac_prefs, e.g. comma separated or space separated? does it allow white spaces? 2. GRUUs can also contain a destination list, but there is no mechanism to specify contact preferences. 3. The draft allow a single SIP registration kind to carry multiple dictionary entries (multiple device for the same AOR). There is no mechanism to specify contact preference across dictionary entries. Perhaps the draft can simply mandate that the order of the multi-entry destination list implies their call preference, which means the owner of the registration must pre-sort the list before storing it. This can eliminate the contact preference field and have a unified way that also covers GRUU. Thanks --Michael Cullen Jennings wrote: > Just wanted to say yep, this is what we meant. > > On Jan 6, 2010, at 8:53 PM, Michael Chen wrote: > > >> Found it. RFC3261 Section 10.2.1.2. Suggest quoting just that so it reads: >> >> SipRegistration.SipRegistrationData.contact_prefs >> >> o If the registration is of type "sip_registration_route", then the >> contents are an opaque string containing the callee's contact >> preferences (as defined in RFC3261 Section 10.2.1.2) and a destination >> list for the peer. >> >> I assume the actual value of the contact preference will be a string like >> >> "0.7" or "0.1", etc. >> >> Thanks >> >> --Michael >> >> -------- Original Message -------- >> Subject: What is SipRegistrationData.contact_prefs? >> From: "Michael Chen" >> Date: Tue, January 05, 2010 4:59 pm >> To: p2psip@ietf.org >> >> Hi, >> >> In the current draft-ietf-p2psip-sip-03, there is no definition for field: >> >> SipRegistration.SipRegistrationData.contact_prefs >> >> o If the registration is of type "sip_registration_route", then the >> contents are an opaque string containing the callee's contact >> preferences and a destination list for the peer. >> >> What is contact preferences? >> >> Thanks >> >> --Michael >> From michaelc@idssoftware.com Sat Jan 16 09:14: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 991A63A68AC for ; Sat, 16 Jan 2010 09:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivro7OXXSVxj for ; Sat, 16 Jan 2010 09:14:38 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 4DB863A6403 for ; Sat, 16 Jan 2010 09:14:38 -0800 (PST) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NWCEN-0008UL-5j for p2psip@ietf.org; Sat, 16 Jan 2010 12:14:35 -0500 Message-ID: <4B51F40D.2080806@idssoftware.com> Date: Sat, 16 Jan 2010 09:14:53 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da9407b1594d387bb12e87c5b4cc337d24fe6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Subject: [P2PSIP] Skipping "sip:" prefix in hash input for Resource 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: Sat, 16 Jan 2010 17:14:39 -0000 Hi, In the current sip-03 draft, the access policy is USER-NODE-MATCH, which requires the AOR matches the rfc822Name in the X509v3 certificate (section 10.3 of base-06 draft). rfc822Name is in the format of "name@domain", so the usual SIP AOR format "sip:name@domain" is not a valid rfc822Name for the X509v3 certificate. Therefore, when obtaining the Resource ID from a SIP AOR, the input to the hashing function must skip the "sip:" prefix. I just want all the principals to verify this and may be noted for implementers in the draft. Thanks --Michael From julian@orchidseed.org Sat Jan 16 09:34: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 317A13A68FC for ; Sat, 16 Jan 2010 09:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+BNAJMgThQy for ; Sat, 16 Jan 2010 09:34:36 -0800 (PST) Received: from n26.c05.mtsvc.net (n26.c05.mtsvc.net [70.32.68.26]) by core3.amsl.com (Postfix) with ESMTP id 5941F3A6403 for ; Sat, 16 Jan 2010 09:34:36 -0800 (PST) Received: from adsl-176-186-129.asm.bellsouth.net ([74.176.186.129]:47526 helo=[172.16.1.230]) by n26.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NWCXe-0000ef-V6; Sat, 16 Jan 2010 09:34:32 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jc In-Reply-To: <4B51EE87.6060002@idssoftware.com> Date: Sat, 16 Jan 2010 12:34:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100106205335.61e8c06078a3b23a733c71e914c0b9df.27b3568a6c.wbe@email.secureserver.net> <4B51EE87.6060002@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] What is SipRegistrationData.contact_prefs? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 17:34:37 -0000 On Jan 16, 2010, at 11:51 AM, Michael Chen wrote: > Cullen, >=20 > There are some related problems for the sip-03 draft: >=20 > 1. When multiple destinations are specified in the structure, the = draft is not clear how the contact preference for each destination is = specified in the single contac_prefs, e.g. comma separated or space = separated? does it allow white spaces? >=20 > 2. GRUUs can also contain a destination list, but there is no = mechanism to specify contact preferences. >=20 > 3. The draft allow a single SIP registration kind to carry multiple = dictionary entries (multiple device for the same AOR). There is no = mechanism to specify contact preference across dictionary entries. >=20 > Perhaps the draft can simply mandate that the order of the multi-entry = destination list implies their call preference, which means the owner of = the registration must pre-sort the list before storing it. This can = eliminate the contact preference field and have a unified way that also = covers GRUU. Who would the "owner" of the registration be? For instance with my = implementation my iphone registers as a peer, a few desktops as peers = and nodes all under the same AOR and I Join a single other AOR as a = Callee to test. All of my devices ring and receive chat messages however = again who actually owns the registration? Nobody, the certificate = belonging to the AOR owns the registration correct? >=20 > Thanks >=20 > --Michael >=20 > Cullen Jennings wrote: >> Just wanted to say yep, this is what we meant. >>=20 >> On Jan 6, 2010, at 8:53 PM, Michael Chen wrote: >>=20 >> =20 >>> Found it. RFC3261 Section 10.2.1.2. Suggest quoting just that so it = reads: >>>=20 >>> SipRegistration.SipRegistrationData.contact_prefs >>>=20 >>> o If the registration is of type "sip_registration_route", then = the >>> contents are an opaque string containing the callee's contact >>> preferences (as defined in RFC3261 Section 10.2.1.2) and a = destination >>> list for the peer. >>>=20 >>> I assume the actual value of the contact preference will be a string = like >>>=20 >>> "0.7" or "0.1", etc. >>>=20 >>> Thanks >>>=20 >>> --Michael >>>=20 >>> -------- Original Message -------- >>> Subject: What is SipRegistrationData.contact_prefs? >>> From: "Michael Chen" >>> Date: Tue, January 05, 2010 4:59 pm >>> To: p2psip@ietf.org >>>=20 >>> Hi, >>>=20 >>> In the current draft-ietf-p2psip-sip-03, there is no definition for = field: >>>=20 >>> SipRegistration.SipRegistrationData.contact_prefs >>>=20 >>> o If the registration is of type "sip_registration_route", then = the >>> contents are an opaque string containing the callee's contact >>> preferences and a destination list for the peer. >>>=20 >>> What is contact preferences? >>>=20 >>> Thanks >>>=20 >>> --Michael >>> =20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From julian@orchidseed.org Sat Jan 16 09:38:09 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E633A6962 for ; Sat, 16 Jan 2010 09:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0km3rV3qX+Vc for ; Sat, 16 Jan 2010 09:38:09 -0800 (PST) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id 15E583A693D for ; Sat, 16 Jan 2010 09:38:09 -0800 (PST) Received: from adsl-176-186-129.asm.bellsouth.net ([74.176.186.129]:48663 helo=[172.16.1.230]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NWCb6-0004cW-NF; Sat, 16 Jan 2010 09:38:06 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jc In-Reply-To: <4B51F40D.2080806@idssoftware.com> Date: Sat, 16 Jan 2010 12:38:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1ED0E3D2-3F43-4963-B850-B37DA8B46B21@orchidseed.org> References: <4B51F40D.2080806@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: P2PSIP WG Subject: Re: [P2PSIP] Skipping "sip:" prefix in hash input for Resource 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: Sat, 16 Jan 2010 17:38:09 -0000 Michael, I do as you mention, drop the four character prefix "sip:" and hash the = AOR. Julian Cain On Jan 16, 2010, at 12:14 PM, Michael Chen wrote: > Hi, >=20 > In the current sip-03 draft, the access policy is USER-NODE-MATCH, = which requires the AOR matches the rfc822Name in the X509v3 certificate = (section 10.3 of base-06 draft). >=20 > rfc822Name is in the format of "name@domain", so the usual SIP AOR = format "sip:name@domain" is not a valid rfc822Name for the X509v3 = certificate. Therefore, when obtaining the Resource ID from a SIP AOR, = the input to the hashing function must skip the "sip:" prefix. >=20 > I just want all the principals to verify this and may be noted for = implementers in the draft. >=20 > Thanks >=20 > --Michael > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From davidbryan@gmail.com Tue Jan 19 05: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 CC7C83A691B for ; Tue, 19 Jan 2010 05:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, 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 9n7rrKeDg-z3 for ; Tue, 19 Jan 2010 05:59:37 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 062D43A6846 for ; Tue, 19 Jan 2010 05:59:36 -0800 (PST) Received: by yxe30 with SMTP id 30so683441yxe.29 for ; Tue, 19 Jan 2010 05:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=YiAlj1KzicZSPMOI1kDdDZo62tExVqQJSpdYfynvDHY=; b=Jd8TCZPa35C4pRLQcRpj1FRiajYlaMuE3yEYgI1oUQbl/ALiM4EP8/FK+rOmjA78Gp eXxtcrdbe0gXn4otN7GyoyMAZn0B/yIWpSu2ymTpn+OuDRL7xzX89GqX+8Xv3t3Pn1VO LwiIS2RhEThNwHDJcuHvbWvA+SmUDvOQd67o8= 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=rHM2lOfsFhVS80rHzdbw1nJxels62xYNjgAym6tbhTRzncXRGsXOE/rSp8/uDdN+/z QaArJKexL0if9U25PKhOuKLIAGohdEggFLbrYSyUosXGEcnjuEE8uqNRGpQilV8A3GMg rX+HlqEZWa7nYpfsNuu2+ISdrN5egywD8pz68= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.163.4 with SMTP id l4mr7523808ybe.300.1263909566771; Tue, 19 Jan 2010 05:59:26 -0800 (PST) In-Reply-To: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> References: <8b2769930912070707p1a1ae49bs8dfa3ad49e8ecbd4@mail.gmail.com> Date: Tue, 19 Jan 2010 08:59:26 -0500 X-Google-Sender-Auth: 2d2f03e86b2996b4 Message-ID: <8b2769931001190559p68e495a3ndb7db5b41de96879@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [P2PSIP] List hum to adopt draft-maenpaa-p2psip-service-discovery-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 13:59:37 -0000 (I am nearly certain this got sent to the list back in December, but there is no evidence of it in the archives. As the authors are looking to submit the next rev, I'll resend) Since there was overwhelming list support (and no objections) to this draft, we'll take this up as the WG item. Thanks, David (as chair) On Mon, Dec 7, 2009 at 10:07 AM, David A. Bryan wrote: > We've had a request from the authors of > draft-maenpaa-p2psip-service-discovery-00 to ask for a list hum to > adopt this draft as a WG item to fulfill the new milestone for a WG > item on service discovery that was approved at the Hiroshima meeting. > > So, we are taking a hum on list of the group if they would like to see > this draft (http://tools.ietf.org/html/draft-maenpaa-p2psip-service-discovery-00) > adopted to meet that new milestone. We'll leave things open for > comments until Tuesday, December 15th. As usual, please send comments > either way to the list. > > Thanks, > > David (as chair) > From root@core3.amsl.com Tue Jan 19 07:15:07 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 02F8D28C0E2; Tue, 19 Jan 2010 07:15:04 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100119151507.02F8D28C0E2@core3.amsl.com> Date: Tue, 19 Jan 2010 07:15:05 -0800 (PST) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-service-discovery-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 15:15:08 -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-00.txt Pages : 13 Date : 2010-01-19 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 23, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-19070020.I-D@ietf.org> --NextPart-- From michaelc@IDSSOFTWARE.COM Wed Jan 20 20:22:02 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 F193D3A68CB for ; Wed, 20 Jan 2010 20:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.442 X-Spam-Level: * X-Spam-Status: No, score=1.442 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 y6Dq6uwibLKd for ; Wed, 20 Jan 2010 20:22:01 -0800 (PST) Received: from smtpoutwbe03.prod.mesa1.secureserver.net (smtpoutwbe03.prod.mesa1.secureserver.net [208.109.78.114]) by core3.amsl.com (Postfix) with SMTP id 225923A68C6 for ; Wed, 20 Jan 2010 20:22:00 -0800 (PST) Received: (qmail 5023 invoked from network); 21 Jan 2010 04:21:56 -0000 Received: from unknown (HELO gem-wbe32.prod.mesa1.secureserver.net) (64.202.189.144) by smtpoutwbe03.prod.mesa1.secureserver.net with SMTP; 21 Jan 2010 04:21:56 -0000 Received: (qmail 1732 invoked by uid 99); 21 Jan 2010 04:21:56 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.2.03 Message-Id: <20100120212156.61e8c06078a3b23a733c71e914c0b9df.699d2dd9bc.wbe@email.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Wed, 20 Jan 2010 21:21:56 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Value for AttachReqAns.role 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, 21 Jan 2010 04:22:02 -0000

Hi,

Regarding the value for AttachRe= qAns.role:

    /*
  &n= bsp; * RELOAD 5.5.1.8. Role Determination
    *
=    * "The roles of controlling and controlled as described in Sec= tion 5.2
    * of ICE are still utilized with RELOA= D. However, the offerer (the
    * entity sen= ding the Attach request) will always be controlling, and
  &nb= sp; * the answerer (the entity sending the Attach response) will alwa= ys be
    * controlled."
    *    * RELOAD 5.5.1.13. Sending Media
    = *
    * "Consequently, once ICE processing completes, the= agent will begin
    * TLS or DTLS procedures to = establish a secure connection. The node
    * which= sent the Attach request MUST be the TLS server. The other
&= nbsp; * node MUST be the TLS client."
    *    * Therefore, according to RFC-4145, the offerer (ICE c= ontrolling)
    * MUST take the 'passive' role and the an= swerer (ICE controlled)
    * MUST take the 'active' role= .
    */

I want the group to= confirm this, because it seems counter-intuitive. If this

is tru= e, then I suggest the following change to the definition of 'role' in

section 5.5.1.1 to help implementers avoid a critical mistake:

role

An a= ctive/passive/actpass attribute from RFC 4145 [RFC4145].

&n= bsp; This value MUST be 'passive' for the offerer (the pe= er sending

the Attach request) and= 'active' for the answerer (the peer

&nbs= p; sending the Attach response).

Thanks

<= div>

--Michael

From julian@orchidseed.org Thu Jan 21 09:10: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 E0C773A6A28 for ; Thu, 21 Jan 2010 09:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRjNfhg8TwQg for ; Thu, 21 Jan 2010 09:10:52 -0800 (PST) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 1507F3A69C3 for ; Thu, 21 Jan 2010 09:10:50 -0800 (PST) Received: from adsl-176-186-129.asm.bellsouth.net ([74.176.186.129]:41537 helo=[172.16.1.230]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NY0YO-0000aq-Ei; Thu, 21 Jan 2010 09:10:46 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1-171314748 From: jc In-Reply-To: <20100120212156.61e8c06078a3b23a733c71e914c0b9df.699d2dd9bc.wbe@email.secureserver.net> Date: Thu, 21 Jan 2010 12:10:39 -0500 Message-Id: <1CAAF54A-8D5B-47AA-BF32-89FB398EBF3F@orchidseed.org> References: <20100120212156.61e8c06078a3b23a733c71e914c0b9df.699d2dd9bc.wbe@email.secureserver.net> To: Michael Chen X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Value for AttachReqAns.role 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, 21 Jan 2010 17:10:54 -0000 --Apple-Mail-1-171314748 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I second this amendment because without prior knowledge of RELOAD I can = see implementors wondering about this ICE /TCP scenario. Julian On Jan 20, 2010, at 11:21 PM, Michael Chen wrote: > Hi, >=20 > Regarding the value for AttachReqAns.role: >=20 > /* > * RELOAD 5.5.1.8. Role Determination > * > * "The roles of controlling and controlled as described in Section = 5.2 > * of ICE are still utilized with RELOAD. However, the offerer = (the > * entity sending the Attach request) will always be controlling, = and > * the answerer (the entity sending the Attach response) will = always be > * controlled." > * > * RELOAD 5.5.1.13. Sending Media > * > * "Consequently, once ICE processing completes, the agent will = begin=20 > * TLS or DTLS procedures to establish a secure connection. The = node > * which sent the Attach request MUST be the TLS server. The = other > * node MUST be the TLS client." > * > * Therefore, according to RFC-4145, the offerer (ICE controlling) > * MUST take the 'passive' role and the answerer (ICE controlled) > * MUST take the 'active' role. > */ >=20 > I want the group to confirm this, because it seems counter-intuitive. = If this > is true, then I suggest the following change to the definition of = 'role' in > section 5.5.1.1 to help implementers avoid a critical mistake: >=20 > role > An active/passive/actpass attribute from RFC 4145 [RFC4145]. > This value MUST be 'passive' for the offerer (the peer sending > the Attach request) and 'active' for the answerer (the peer > sending the Attach response). >=20 > Thanks >=20 > --Michael > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1-171314748 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = second this amendment because without prior knowledge of RELOAD I can = see implementors wondering about this ICE /TCP = scenario.

Julian

On Jan 20, = 2010, at 11:21 PM, Michael Chen wrote:

Hi,

Regarding the value = for AttachReqAns.role:

    = /*
    * RELOAD 5.5.1.8. Role = Determination
    *
    * "The roles = of controlling and controlled as described in Section = 5.2
    * of ICE are still utilized with = RELOAD. However, the offerer (the
    * = entity sending the Attach request) will always be controlling, = and
    * the answerer (the entity sending the = Attach response) will always be
    * = controlled."
    *
    * RELOAD = 5.5.1.13. Sending Media
    *
    * = "Consequently, once ICE processing completes, the agent will begin =
    * TLS or DTLS procedures to establish a = secure connection. The node
    * which sent the = Attach request MUST be the TLS server. The = other
    * node MUST be the TLS = client."
    *
    * Therefore, = according to RFC-4145, the offerer (ICE = controlling)
    * MUST take the 'passive' role and = the answerer (ICE controlled)
    * MUST take the = 'active' role.
    */

I = want the group to confirm this, because it seems counter-intuitive. If = this
is true, then I suggest the following change to the = definition of 'role' in
section 5.5.1.1 to help implementers = avoid a critical mistake:

= role
      An active/passive/actpass = attribute from RFC 4145 = [RFC4145].
      This value MUST be = 'passive' for the offerer (the peer = sending
      the Attach request) and = 'active' for the answerer (the = peer
      sending the Attach = response).

Thanks

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

= --Apple-Mail-1-171314748-- From sunchw@gmail.com Thu Jan 21 19:23:52 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E473A6834 for ; Thu, 21 Jan 2010 19:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpBGqYMEYEsT for ; Thu, 21 Jan 2010 19:23:51 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 953713A67F6 for ; Thu, 21 Jan 2010 19:23:51 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e21so144232fga.13 for ; Thu, 21 Jan 2010 19:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=1gQz6h/fSzEN5fWwcb5JYAvTrL2L/0B/dUatmADselc=; b=vFWtKelDPfDo9SRh/Y+rJEp7Rg6ZJ6KLw1ivAa1Uq+u98P1mqhoSLB7VMWEmvkYmRa Bb575gqL2MQypYHPAYkTo2aQB57HeYFvCW/lhSJIi0oDsAjBUE2d2KPT5mRBby0Mun7t I/H86FdFVKKIB+69lmgnTfgAtN8r2ZcegT2UM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qc3dIav9kHS++v1X6EcqdeCr3mHSkrHKznTujnVkocWcxAQQmKYZOyCChKyntZ01Tw RCFwONSrTxzeIkMXhz6g28qCADkCpJZ+GWAGgyLYpSaM2l7frjWlve+ANPiCR/8pYdNC kR4NAnmZQJbmu02v2YV7/E7tNDkzKH+72xeWk= MIME-Version: 1.0 Received: by 10.239.185.206 with SMTP id d14mr270190hbh.150.1264130623825; Thu, 21 Jan 2010 19:23:43 -0800 (PST) Date: Fri, 22 Jan 2010 11:23:43 +0800 Message-ID: From: Sun Chongwei To: P2PSIP WG Content-Type: multipart/alternative; boundary=001485f5cec6c8682b047db858db Subject: [P2PSIP] enrollment server and credential server X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 03:23:52 -0000 --001485f5cec6c8682b047db858db Content-Type: text/plain; charset=ISO-8859-1 hi everyone I have a puzzle after reading the fallowing contents in base-06 draft. in the 1st paragraph of 10.3 Page.115 "A peer which does not yet have credentials MUST contact the credential server to acquire them" in the 1st paragraph of 3.6.2 Page. 28 "In that case,the configuration document will to contain the address of an enrollement server which can be used to obtain such a certificate" but in configuration file issued in 10.1, there is only "credential-server" item, no enrolment server. How could the node know the enrollment server's address? -- Sun Chongwei Mobile LIfe and New Media Lab Beijing University of Posts and Telecommunications --001485f5cec6c8682b047db858db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

hi everyone

I have a puzzle =A0after readi= ng the fallowing contents in base-06 draft.

in the= 1st paragraph of 10.3 =A0 Page.115

"A peer which does not y= et have credentials MUST contact the credential server to acquire them"= ;

in the 1st paragraph of 3.6.2 =A0 Page. 28

&q= uot;In that case,the configuration document will to contain the address of = an enrollement server which can be used to obtain such a certificate"<= /div>

but in configuration file issued in 10.1, there is only= "credential-server" item, no enrolment server.

How could the node know the enrollment server's address?

--
Sun Chongwei
Mobile LIfe and New Media Lab
Beijing Univers= ity of Posts and Telecommunications
--001485f5cec6c8682b047db858db-- From davidbryan@gmail.com Thu Jan 21 21:50:25 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7823A6809 for ; Thu, 21 Jan 2010 21:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ocp5QsvKOc00 for ; Thu, 21 Jan 2010 21:50:25 -0800 (PST) Received: from mail-yw0-f201.google.com (mail-yw0-f201.google.com [209.85.211.201]) by core3.amsl.com (Postfix) with ESMTP id F2AC23A6358 for ; Thu, 21 Jan 2010 21:50:24 -0800 (PST) Received: by ywh39 with SMTP id 39so1760899ywh.17 for ; Thu, 21 Jan 2010 21:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=sH+20QkELtsNjMUXJ6Xw5Q3pnOqORGxkmngIFZjzkc8=; b=RCtPcMdHmXB4qD0xJFXChjwoyQY4GuOLmcxZn2pdEhYoem5e7jUr07FJCZvarXdILj v5daJYmWjwGvWpM2FlNi8QvD4/Kdm6gj6RiQaRlwDfn92IAHTU7iWDgxHBIi6ec3Ldxu az7SNzdH5xcuOiXCIQG/lZQQsFKnM56MDKWgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rOGoQe4xvcBSPyZYhwVRctTivBC77L9dpTe11QEslhBVjAFN+TXO73tNt0R3SGpf9a 4D6bxH8+g66dbyBH5K8zEhGsGDIRf57sUH+WqvxCqU1plCX+6VUysrUcOSa9VGZ+1m5z engFuTou7ML78lWwzeSFt6sA6nE+VjtWMfqbQ= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.118.37 with SMTP id q37mr3436519ybc.322.1264139415159; Thu, 21 Jan 2010 21:50:15 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Jan 2010 00:50:15 -0500 X-Google-Sender-Auth: e56fabb424019197 Message-ID: <8b2769931001212150i1145e684me9ac9e7972055fff@mail.gmail.com> From: "David A. Bryan" To: Sun Chongwei Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] enrollment server and credential server X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 05:50:25 -0000 I believe in this context the two terms (credential server and enrollment server) mean the same thing. It should probably be clarified in the document. David (as individual) On Thu, Jan 21, 2010 at 10:23 PM, Sun Chongwei wrote: > hi everyone > I have a puzzle =A0after reading the fallowing contents in base-06 draft. > in the 1st paragraph of 10.3 =A0 Page.115 > "A peer which does not yet have credentials MUST contact the credential > server to acquire them" > in the 1st paragraph of 3.6.2 =A0 Page. 28 > "In that case,the configuration document will to contain the address of a= n > enrollement server which can be used to obtain such a certificate" > but in configuration file issued in 10.1, there is only "credential-serve= r" > item, no enrolment server. > How could the node know the enrollment server's address? > -- > Sun Chongwei > Mobile LIfe and New Media Lab > Beijing University of Posts and Telecommunications > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From hocs@itri.org.tw Thu Jan 21 23:11: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 DFB153A68F5 for ; Thu, 21 Jan 2010 23:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.787 X-Spam-Level: *** X-Spam-Status: No, score=3.787 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_TW=1.335, 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 v1kxwkPOTYun for ; Thu, 21 Jan 2010 23:11:42 -0800 (PST) Received: from maillog2.itri.org.tw (maillog.itri.org.tw [61.61.254.20]) by core3.amsl.com (Postfix) with ESMTP id 64A143A67AE for ; Thu, 21 Jan 2010 23:11:40 -0800 (PST) Received: from mail.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by maillog2.itri.org.tw with ESMTP id o0M7BUmr022380 for ; Fri, 22 Jan 2010 15:11:30 +0800 (CST) (envelope-from hocs@itri.org.tw) Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id o0M7BUBu029907 for ; Fri, 22 Jan 2010 15:11:30 +0800 (CST) Received: from ms22.itri.org.tw (ms22.itri.org.tw [140.96.151.74]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id o0M7BTeD029882 for ; Fri, 22 Jan 2010 15:11:30 +0800 (CST) Received: from 52092035394 ([140.96.151.239]) by ms22.itri.org.tw (Lotus Domino Release 7.0.3FP1) with ESMTP id 2010012215112811-2225 ; Fri, 22 Jan 2010 15:11:28 +0800 From: "JeffreyHo" To: Date: Fri, 22 Jan 2010 15:11:29 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqbMh5McLJYPiVHQ6eKt50w5djT0Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-MIMETrack: Itemize by SMTP Server on ms22/ITRI(Release 7.0.3FP1|February 24, 2008) at 2010-01-22 15:11:28, Serialize by Router on ms22/ITRI(Release 7.0.3FP1|February 24, 2008) at 2010-01-22 15:11:30, Serialize complete at 2010-01-22 15:11:30 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01CA9B75.2FB991D0" X-MAIL: maillog2.itri.org.tw o0M7BUmr022380 Cc: =?Big5?B?qEiw+7D7c2hlbg==?= Subject: [P2PSIP] [p2psip] asking about the lifetime of the stored data and refreshing mechanism 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, 22 Jan 2010 07:11:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0045_01CA9B75.2FB991D0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Dear all, I would like to ask a question about the lifetime of the stored data and refresh behavior sequentially. The 'lifetime' field of RELOAD's StoredData structure specifies the validity period for the data, that is the expiration time in the overlay. So if the data owner wants to keep the data previously stored still validity, the refresh behavior is necessary, just like the registration refresh in SIP Concept. Based on the StoredData structure if we want to do refresh for the data, it seems that we can just send StoreReq with the content of data again to renew the 'lifetime' value. Am I right? If so, this seems in the wasted way. Can we have an efficient way to do the refresh behavior, for example just bringing the lifetime value to be renewed for the data, not going along with the data content? It could be like the refresh mechanism of SIP registration or presence publication. Should we go this way? Thanks a lot. BR, Jeffrey %;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. ------=_NextPart_000_0045_01CA9B75.2FB991D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="big5" [p2psip] asking about the lifetime of the stored data and refreshing= mechanism

Dear all,

I would like to ask a question= about the lifetime of the stored data and refresh behavior sequentially.=
The 'lifetime' field of= RELOAD's StoredData structure specifies the validity period for the data,= that is the expiration time in the overlay. So if the data owner= wants to keep the data previously stored still validity, the refresh= behavior is necessary, just like the registration refresh in SIP Concept.=

Based on the StoredData= structure if we want to do refresh for the data, it seems that we can just= send StoreReq with the content of data again to renew the 'lifetime'= value. Am I right? If so, this seems in the wasted way. = Can we have an efficient way to do the refresh behavior, for example just= bringing the lifetime value to be renewed for the data, not going along= with the data content? It could be like the refresh mechanism of SIP= registration or presence publication. Should we go this= way?

Thanks a lot.

BR,
Jeffrey

=A5=BB=ABH=A5=F3=A5i= =AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1K=B8=EA=B0T=A1A=ABD=AB=FC=A9w=A4=A7=A6= =AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5=A8=CF=A5=CE=A9=CE=B4=A6=C5S=A5=BB=ABH=A5=F3= =A4=BA=AEe=A1A=A8=C3=BD=D0=BEP=B7=B4=A6=B9=ABH=A5=F3=A1C
This email may contain confidential information. Please do not use or= disclose it in any way and delete it if you are not the intended= recipient.

------=_NextPart_000_0045_01CA9B75.2FB991D0-- From zainab.khallouf@gmail.com Sat Jan 23 12:05:21 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33443A684D for ; Sat, 23 Jan 2010 12:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qpb3JH5UF+V0 for ; Sat, 23 Jan 2010 12:05:21 -0800 (PST) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id C01F83A63C9 for ; Sat, 23 Jan 2010 12:05:20 -0800 (PST) Received: by ewy26 with SMTP id 26so609153ewy.28 for ; Sat, 23 Jan 2010 12:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=HSd1Vs4sS9j4OaAhSbJLcG6e9V177U7UcUE7ubblM/A=; b=lo3/qPbZe7NCI6FU6sR2KdUw67QnUoNL/a9wC4F8j+nn7zJovPrJNitAGwtumNvOvl b1et+9NkPSglkoljhxQK9sEiBM0H07IQ2p18E7sXn/vrLHeU0phJPFyCVo9F0ZSKoEJQ 4c2Kh3kXmrJqM3/0WdlgFxR+8QyR+STeIMsZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cQ4gnea9q2xIvRv+rQNSgqRm5TCByMFSeLMoSGtRop4C4+6YcXxRF9hy+SL9aub7Ma EAaPFM6yFXuOzq8/D57+NrI3oiTeVDhGV/PT8yIkCnTToosi9qjQGykUg1Hr2EnYI3GA kbSzo3EzqMjMP6s7WCYExAD2pmQoJh2a7r7zQ= MIME-Version: 1.0 Received: by 10.216.90.78 with SMTP id d56mr1737068wef.126.1264277113207; Sat, 23 Jan 2010 12:05:13 -0800 (PST) Date: Sat, 23 Jan 2010 22:05:13 +0200 Message-ID: From: zainab khallouf To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Question about the use of SAML with P2P SIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 20:06:58 -0000 Dear all, I would like to ask about the use of SAML to build trust P2P SIP. Any new researches or standardization efforts in this area? I would like to know if it would be interesting to publish a draft trying to define a profile SAML for P2P SIP ? Thanks, http://sites.google.com/site/zainabkhallouf/ From ekr@rtfm.com Sat Jan 23 13:36: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 90D833A6806 for ; Sat, 23 Jan 2010 13:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d-4E03o1AxZ for ; Sat, 23 Jan 2010 13:36:41 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id E85B33A67BE for ; Sat, 23 Jan 2010 13:36:40 -0800 (PST) Received: by pxi16 with SMTP id 16so1640015pxi.29 for ; Sat, 23 Jan 2010 13:36:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.188.31 with SMTP id l31mr3189767waf.119.1264282592134; Sat, 23 Jan 2010 13:36:32 -0800 (PST) In-Reply-To: References: Date: Sat, 23 Jan 2010 13:36:32 -0800 Message-ID: From: Eric Rescorla To: zainab khallouf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question about the use of SAML with P2P SIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 21:36:41 -0000 It's not clear to me what this would do... P2PSIP already has a pretty clea= r authentication and authorization structure, so what would SAML bring to the party? -Ekr On Sat, Jan 23, 2010 at 12:05 PM, zainab khallouf wrote: > Dear all, > I would like to ask =A0about the use of SAML to build trust P2P SIP. > Any new researches or standardization efforts in this area? > I would like to know if it would be interesting to publish a draft > trying to define a profile SAML for P2P SIP ? > Thanks, > http://sites.google.com/site/zainabkhallouf/ > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From zainab.khallouf@gmail.com Sat Jan 23 22:33:13 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337A93A6808 for ; Sat, 23 Jan 2010 22:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 mwXRWvJEpfJd for ; Sat, 23 Jan 2010 22:33:12 -0800 (PST) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 3524F3A67EB for ; Sat, 23 Jan 2010 22:33:12 -0800 (PST) Received: by ewy26 with SMTP id 26so949473ewy.28 for ; Sat, 23 Jan 2010 22:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aayxYaRxMnpe9y3HpmvfyxpgMLcToilgaOrjR6hWxDc=; b=DKDtsOkwJXEY9oupb0Qil1r41ZNU8VVhQE1A1OB+mWuVfBE18l1JFZAoWczUGeMLGr u78r4TZSLcx+6LZ+egRVEwvGOODHvIQQqTIh92A3CSQq8FvSii4thn/sAba8tBuBwl6/ QEh+Tmqxv3W8hni80WA0GcbiZfCzz3ErCd/5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BPyEqBFK9b3UsuYzPznuXBYEK8k5RZU8RgPsMKP+URl397PzTwyumB/PNztrThpI1I 7Vraa8W9XXjyfFaeqBVozEOprP1iU6kBfo5tYUIFEhOtEkdzChjjFZovMturc48gNmZa SSXme/7JGw6DVvOACiBc5y6MnIpWuWyXPGAW0= MIME-Version: 1.0 Received: by 10.216.172.203 with SMTP id t53mr2006031wel.56.1264314789626; Sat, 23 Jan 2010 22:33:09 -0800 (PST) In-Reply-To: References: Date: Sun, 24 Jan 2010 08:33:09 +0200 Message-ID: From: zainab khallouf To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question about the use of SAML with P2P SIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 06:33:13 -0000 On 1/23/10, Eric Rescorla wrote: > It's not clear to me what this would do... P2PSIP already has a pretty clear > authentication and authorization structure, so what would SAML bring > to the party? As far as I know, these solutions rely mostly on centralized authentication authority, or adhoc approaches. Using SAML with P2P SIP allows to include a broad category of authentication solutions: centralized or decentralized approaches like the web of trust approaches, this what I tried to introduce in my paper (Trust Management in Peer-to-Peer SIP Using the Security Assertion Markup Language). The draft (draft-ietf-sip-saml-06.txt) defines a profile SAML to be used with SIP, but the daft does not define a profile to be used with P2P SIP. Thanks, http://sites.google.com/site/zainabkhallouf/ From ekr@rtfm.com Sun Jan 24 07:09:56 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDC33A6A15 for ; Sun, 24 Jan 2010 07:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 J2J7cPMsVyri for ; Sun, 24 Jan 2010 07:09:56 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 275ED3A6A14 for ; Sun, 24 Jan 2010 07:09:56 -0800 (PST) Received: by yxe30 with SMTP id 30so517116yxe.29 for ; Sun, 24 Jan 2010 07:09:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.37.31 with SMTP id k31mr4618525agk.107.1264345795360; Sun, 24 Jan 2010 07:09:55 -0800 (PST) In-Reply-To: References: Date: Sun, 24 Jan 2010 07:09:55 -0800 Message-ID: From: Eric Rescorla To: zainab khallouf Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question about the use of SAML with P2P SIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 15:09:57 -0000 On Sat, Jan 23, 2010 at 10:33 PM, zainab khallouf wrote: > On 1/23/10, Eric Rescorla wrote: >> It's not clear to me what this would do... P2PSIP already has a pretty clear >> authentication and authorization structure, so what would SAML bring >> to the party? > > > As far as I know, these solutions rely mostly on centralized > authentication authority, or adhoc approaches. > Using SAML with P2P SIP allows to include a broad category of > authentication solutions: centralized or decentralized approaches like > the web of trust approaches, this what I tried to introduce in my > paper (Trust Management in Peer-to-Peer SIP Using the Security > Assertion Markup Language). > The draft (draft-ietf-sip-saml-06.txt) defines a profile SAML to be > used with SIP, but the daft does not define a profile to be used with > P2P SIP. I can't access this article because it's on IEEE Xplor, but I don't really see how this is going to work. P2P networks start to fall apart rapidly with significant fractions of malicious nodes. In a WoT system, you're not going to have any plausible information about the vast majority of the nodes in the network, so I don't see how this is going to be secure. If you submit a draft, I will of course take a look. -Ekr From edpimentl@gmail.com Sun Jan 24 08:11:22 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 C00973A688D for ; Sun, 24 Jan 2010 08:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 uPy-oeeyFGfj for ; Sun, 24 Jan 2010 08:11:19 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 41F963A68BD for ; Sun, 24 Jan 2010 08:11:19 -0800 (PST) Received: by ywh34 with SMTP id 34so1031718ywh.31 for ; Sun, 24 Jan 2010 08:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=W0ciplU8W0EN7A2CKTFrS+IlrfdTg4O1GU/6EXJH2WU=; b=VZzAOmGnMsNmlHgjLqbbuSO8F7CArM+ZuOedPGaT91yfYZJS7KCkZCeW0fPpKWi5d3 CEAqV1lkEgw8/1L9d7N2pTyzieMjw8Yw+vjVQU59CorsPjOh+omT/dp4/1Er0M2+jNA+ z7CXPbHIMdSVOr3O/AhYstxZjXZGtUXpG7hyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=VnTx9Jkqnv3n3iCsZUfef+/1wspRvavUS+4pThfA/1X5IYj+kI0XmYiXfsaD7P53OK vG4LzbbgiI7VQZdxFhRa65s/5beAGLBzXvO+FLEHuT1VV6DcUC0JQOsDPfkJ0MK7fXwJ udr5vowb4zeEoEpuiDTPvr5iMQNlL4tAMIUo8= MIME-Version: 1.0 Received: by 10.101.82.11 with SMTP id j11mr6571506anl.86.1264349477130; Sun, 24 Jan 2010 08:11:17 -0800 (PST) In-Reply-To: References: From: EdPimentl Date: Sun, 24 Jan 2010 11:10:57 -0500 Message-ID: <9dc4a1671001240810w7c5add24k4614e118bdda787b@mail.gmail.com> To: Eric Rescorla Content-Type: multipart/alternative; boundary=001636ed6dfd74d1d1047deb4dc7 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question about the use of SAML with P2P SIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 16:11:23 -0000 --001636ed6dfd74d1d1047deb4dc7 Content-Type: text/plain; charset=UTF-8 Concur with Eric on embracing what p2psip is working on. Look into OpenID, OSP and Higgins for your solution. No doubt, Cullen, Henry, and David will have excellent links to point you to. Sincerely, -E http://vCardCloud.com http://iotcloud.com (The Internet of Things Cloud) --001636ed6dfd74d1d1047deb4dc7 Content-Type: text/html; charset=UTF-8 Concur with Eric on embracing what p2psip is working on.
Look into OpenID, OSP and Higgins for your solution.

No doubt, Cullen, Henry, and David will have excellent links to point you to.

Sincerely,
-E
http://vCardCloud.com
http://iotcloud.com (The Internet of Things Cloud)

--001636ed6dfd74d1d1047deb4dc7-- From hocs@itri.org.tw Mon Jan 25 01:00:49 2010 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9223A6782 for ; Mon, 25 Jan 2010 01:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.787 X-Spam-Level: *** X-Spam-Status: No, score=3.787 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_TW=1.335, 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 s9mh7140ivh9 for ; Mon, 25 Jan 2010 01:00:48 -0800 (PST) Received: from maillog1.itri.org.tw (maillog.itri.org.tw [61.61.254.20]) by core3.amsl.com (Postfix) with ESMTP id 64CA83A6405 for ; Mon, 25 Jan 2010 01:00:47 -0800 (PST) Received: from mail.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by maillog1.itri.org.tw with ESMTP id o0P90pYD047226 for ; Mon, 25 Jan 2010 17:00:51 +0800 (CST) (envelope-from hocs@itri.org.tw) Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id o0P90oWc011995 for ; Mon, 25 Jan 2010 17:00:51 +0800 (CST) Received: from ms22.itri.org.tw (ms22.itri.org.tw [140.96.151.74]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id o0P90oUL011992 for ; Mon, 25 Jan 2010 17:00:50 +0800 (CST) Received: from 52092035394 ([140.96.151.239]) by ms22.itri.org.tw (Lotus Domino Release 7.0.3FP1) with ESMTP id 2010012517004934-3402 ; Mon, 25 Jan 2010 17:00:49 +0800 From: "JeffreyHo" To: References: Date: Mon, 25 Jan 2010 17:00:44 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: Thread-Index: AcqbMh5McLJYPiVHQ6eKt50w5djT0QCYtIAg X-MIMETrack: Itemize by SMTP Server on ms22/ITRI(Release 7.0.3FP1|February 24, 2008) at 2010-01-25 17:00:49, Serialize by Router on ms22/ITRI(Release 7.0.3FP1|February 24, 2008) at 2010-01-25 17:00:50, Serialize complete at 2010-01-25 17:00:50 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01CA9DDF.F192D480" X-MAIL: maillog1.itri.org.tw o0P90pYD047226 Subject: Re: [P2PSIP] asking about the lifetime of the stored data and refreshing mechanism X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 09:00:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01CA9DDF.F192D480 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="big5" Dear all, =0D Any comments or idea on this question?=0D I think if we can just specify the refresh purpose in the StoreReq instead of sending a full StoreReq for refresh, it can mitigate the traffic load, right? Welcome to any discussion and feedback. =0D BR, Jeffrey =0D _____ =0D From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of JeffreyHo Sent: Friday, January 22, 2010 3:11 PM To: p2psip@ietf.org Cc: =A8H=B0=FB=B0=FBshen Subject: [P2PSIP] [p2psip] asking about the lifetime of the stored data andrefreshing mechanism Dear all,=0D I would like to ask a question about the lifetime of the stored data and refresh behavior sequentially.=0D The 'lifetime' field of RELOAD's StoredData structure specifies the= validity period for the data, that is the expiration time in the overlay. So if the data owner wants to keep the data previously stored still validity, the refresh behavior is necessary, just like the registration refresh in SIP Concept.=0D Based on the StoredData structure if we want to do refresh for the data, it seems that we can just send StoreReq with the content of data again to= renew the 'lifetime' value. Am I right? If so, this seems in the wasted way. Can we have an efficient way to do the refresh behavior, for example just bringing the lifetime value to be renewed for the data, not going along= with the data content? It could be like the refresh mechanism of SIP registration or presence publication. Should we go this way? =0D Thanks a lot.=0D BR,=0D Jeffrey=0D =A5=BB=ABH=A5=F3=A5i=AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1K=B8=EA=B0T=A1A= =ABD=AB=FC=A9w=A4=A7=A6=AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5=A8=CF=A5=CE=A9=CE=B4= =A6=C5S=A5=BB=ABH=A5=F3=A4=BA=AEe=A1A=A8=C3=BD=D0 =BEP=B7=B4=A6=B9=ABH=A5=F3=A1C This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. =0D =A5=BB=ABH=A5=F3=A5i=AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1K=B8=EA=B0T=A1A= =ABD=AB=FC=A9w=A4=A7=A6=AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5=A8=CF=A5=CE=A9=CE=B4= =A6=C5S=A5=BB=ABH=A5=F3=A4=BA=AEe=A1A=A8=C3=BD=D0=BEP=B7=B4=A6=B9=ABH=A5=F3= =A1C This email may contain confidential information. Please do not use or= disclose it in any way and delete it if you are not the intended= recipient. ------=_NextPart_000_0009_01CA9DDF.F192D480 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="big5" [p2psip] asking about the lifetime of the stored data= and refreshing mechanism

Dear all,

Any comments or idea on this= question?=0D

I think if we can just specify= the refresh=0D purpose in the StoreReq instead of sending a full StoreReq for= refresh,=0D it can mitigate the traffic load, right?

Welcome to any discussion= and=0D feedback.

BR,

Jeffrey

From: p2psip-bounces@ietf.org=0D [mailto:p2psip-bounces@ietf.org] On Behalf Of= JeffreyHo
Sent:=0D Friday, January 22, 2010 3:11 PM
To:= p2psip@ietf.org
Cc:=0D =A8H=B0=FB=B0=FBshen
Subject: [P2PSIP] [p2psip] asking about the= lifetime of the=0D stored data andrefreshing mechanism

Dear all,

I would like to ask a question= about=0D the lifetime of the stored data and refresh behavior sequentially.=0D
The 'lifetime' field= of=0D RELOAD's StoredData structure specifies the validity period for the data,= that=0D is the expiration time in the overlay. So if the data owner wants to= keep=0D the data previously stored still validity, the refresh behavior is= necessary,=0D just like the registration refresh in SIP Concept.

Based on the StoredData= structure if we=0D want to do refresh for the data, it seems that we can just send StoreReq= with=0D the content of data again to renew the 'lifetime' value. Am I= right? =0D If so, this seems in the wasted way. Can we have an efficient way to= do=0D the refresh behavior, for example just bringing the lifetime value to be= renewed=0D for the data, not going along with the data content? It could be like= the=0D refresh mechanism of SIP registration or presence publication. Should= we=0D go this way?

Thanks a lot.

BR,
Jeffrey

=A5=BB=ABH=A5=F3=A5i=AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE= =F7=B1K=B8=EA=B0T=A1A=ABD=AB=FC=A9w=A4=A7=A6=AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5= =A8=CF=A5=CE=A9=CE=B4=A6=C5S=A5=BB=ABH=A5=F3=A4=BA=AEe=A1A=A8=C3=BD=D0=BEP= =B7=B4=A6=B9=ABH=A5=F3=A1C
This email=0D may contain confidential information. Please do not use or disclose= it in=0D any way and delete it if you are not the intended=0D recipient.

------=_NextPart_000_0009_01CA9DDF.F192D480--