From fluffy at cisco.com Tue Jan 2 18:33:27 2007 From: fluffy at cisco.com (Cullen Jennings) Date: Tue, 2 Jan 2007 15:33:27 -0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG Message-ID: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> I want to put the charter on the IESG agenda this thursday so we can discuss it on the next IES call on Jan 11th. I have talked about it with a lot of people and I would like to make a few trivial changes and one significant change. The significant change is adding text along lines of: The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. I think this text is consistent with the current thinking of the folks on this list and what we discussed in the BOF. If people are OK with this, I would like to include this is the version I send to the IESG. The version that goes to IESG next week is not final. Typically after going to IESG it will be sent out for IETF wide comment and we adjust the text at this point. After this it goes back to the IESG for approval as a WG. I have attached a ascii version of my current working version of the charter along with a word document that have change tracking turned on. Please have a look and check that this includes all the latest changes. Thanks, Cullen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Post BOF charter.txt Url: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070102/8bb3c656/PostBOFcharter-0001.txt -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: Post BOF charter.doc Type: application/octet-stream Size: 40448 bytes Desc: not available Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070102/8bb3c656/PostBOFcharter-0001.obj From dbarrett at quinthar.com Tue Jan 2 21:56:58 2007 From: dbarrett at quinthar.com (David Barrett) Date: Tue, 2 Jan 2007 18:56:58 -0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> Message-ID: <04b001c72ee2$d5f30a70$0202a8c0@Quinthar> Sounds good. Noticed a typo: "P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it *located* users and resources." -- I assume you mean "to locate". You write: "P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263." I think this is a really helpful definition of scope. Would it be fair to say that P2PSIP's goals are more or less limited to the scope of RFC 3263 and topics not covered by RFC 3263 (such as voicemail, metadata storage, credentials, encryption, and so forth) are similarly out of scope for P2PSIP? If so, I notice the statement "Similarly, the group will attempt not to make design decisions that preclude anonymous communications systems from being crafted using the protocols defined by this WG." This seems to go beyond the scope of RFC 3263, and I'm curious why this is carved out as an exception. If we must make that exception, to minimize Quixotic design adventures, I'd like to see a more precise definition of "anonymous communications" than is provided by [1]. As it stands, anything short of invisibility to the NSA fails this requirement, which implies that we can't do anything that the NSA couldn't conceivably tap -- which means we can't really do anything at all. I'd like a set of more precisely defined, more realistic requirements if possible. Finally, you write: "The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope." I think this is a really great clarification. To help make our discussion even more concrete, will we define some kind of interface into this credential/bootstrap service? We needn't define precisely how these services work internally, but without a clear understanding of their external interface, it's like building on a sand foundation. -david PS: Thanks for adding "Approaches based on [multicast/dynamic-DNS] technologies may be reasonable ways to solve similar problems but that is not the focus of this WG." This is also a good clarification. [1] http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-usecases-00.html > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > bounces at cs.columbia.edu] On Behalf Of Cullen Jennings > Sent: Tuesday, January 02, 2007 3:33 PM > To: P2P-SIP > Subject: [p2p-sip] P2PSIP Charter ready for IESG > > I want to put the charter on the IESG agenda this thursday so we can > discuss it on the next IES call on Jan 11th. > > I have talked about it with a lot of people and I would like to make > a few trivial changes and one significant change. The significant > change is adding text along lines of: > > The initial work will assume the existence of some enrollment process > that > provides a unique user name, credentials, and an initial set of > bootstrap nodes > if that is required by the protocols. Developing a non-centralized > enrollment > process is not in scope. > > I think this text is consistent with the current thinking of the > folks on this list and what we discussed in the BOF. If people are OK > with this, I would like to include this is the version I send to the > IESG. The version that goes to IESG next week is not final. Typically > after going to IESG it will be sent out for IETF wide comment and we > adjust the text at this point. After this it goes back to the IESG > for approval as a WG. > > I have attached a ascii version of my current working version of the > charter along with a word document that have change tracking turned > on. Please have a look and check that this includes all the latest > changes. > > Thanks, Cullen > From enrico.marocco at telecomitalia.it Wed Jan 3 04:17:42 2007 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Wed, 03 Jan 2007 10:17:42 +0100 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> References: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> Message-ID: <459B74B6.8000605@telecomitalia.it> Cullen Jennings wrote: > I have talked about it with a lot of people and I would like to make a > few trivial changes and one significant change. The significant change > is adding text along lines of: > > The initial work will assume the existence of some enrollment process that > provides a unique user name, credentials, and an initial set of > bootstrap nodes > if that is required by the protocols. Developing a non-centralized > enrollment > process is not in scope. > > I think this text is consistent with the current thinking of the folks > on this list and what we discussed in the BOF. If people are OK with > this, I would like to include this is the version I send to the IESG. I agree. I think the whole text perfectly reflects two years of mail discussions, of conference calls and of ad-hoc and official BOFs. Thank you. -- Ciao, Enrico From drage at alcatel-lucent.com Wed Jan 3 07:03:53 2007 From: drage at alcatel-lucent.com (Drage, Keith (Keith)) Date: Wed, 3 Jan 2007 13:03:53 +0100 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> Message-ID: <5D1A7985295922448D5550C94DE29180A399D4@DEEXC1U01.de.lucent.com> Few minor changes on your changes - assuming the word document is reasonably definitive (The text file seems to have lost all formatting and is therefore pretty unreadable). 1) In the new text: "P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it located users and resources. " We seem to have a typo that needs correction. 2) In the new sentence: "In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP messages." Change "SIP messages" to "SIP requests". 3) I am also not sure that "conventional" improves on "traditional" as an adjective for SIP. They are both equally vague and indeterminate. If your intent was to be more precise, then this fails. 4) On the list of deliverables, the list is introduced by: "This group's primary tasks are to produce:". This text should therefore read direct into the new text for item 3) - which with the proposal does not happen. The intro to item 3 should therefore be (assuming people agree with making it optional): "Optionally, a proposed standard defining a P2PSIP Client Protocol for use by P2PSIP clients, some of which may be behind NATs." 5) I seem to remember a discussion on the current concents document that "peer" and "client" should always be preceded by "P2PSIP". Perhaps a final pass to check the charter terminology with this document. 6) I also note that on the goals and milestones, in other charter changes you have been requesting WGLC dates as well as submission to IESG dates. Perhaps we should add these. Regards Keith > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Cullen Jennings > Sent: 02 January 2007 23:33 > To: P2P-SIP > Subject: [p2p-sip] P2PSIP Charter ready for IESG > > I want to put the charter on the IESG agenda this thursday so > we can discuss it on the next IES call on Jan 11th. > > I have talked about it with a lot of people and I would like > to make a few trivial changes and one significant change. The > significant change is adding text along lines of: > > The initial work will assume the existence of some enrollment > process that provides a unique user name, credentials, and an > initial set of bootstrap nodes if that is required by the > protocols. Developing a non-centralized enrollment process is > not in scope. > > I think this text is consistent with the current thinking of > the folks on this list and what we discussed in the BOF. If > people are OK with this, I would like to include this is the > version I send to the IESG. The version that goes to IESG > next week is not final. Typically after going to IESG it will > be sent out for IETF wide comment and we adjust the text at > this point. After this it goes back to the IESG for approval as a WG. > > I have attached a ascii version of my current working version > of the charter along with a word document that have change > tracking turned on. Please have a look and check that this > includes all the latest changes. > > Thanks, Cullen > > > From spencer at mcsr-labs.org Wed Jan 3 07:19:48 2007 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Wed, 3 Jan 2007 06:19:48 -0600 Subject: [p2p-sip] P2PSIP Charter ready for IESG References: <5D1A7985295922448D5550C94DE29180A399D4@DEEXC1U01.de.lucent.com> Message-ID: <012c01c72f31$76094350$6a01a8c0@china.huawei.com> Just a couple of agreements with Keith... > 3) I am also not sure that "conventional" improves on "traditional" > as an adjective for SIP. They are both equally vague and indeterminate. > If your intent was to be more precise, then this fails. I agree with Keith that "conventional" and "traditional" are indeterminate and will likely mean something different in 10 years. David Barrett's recent note on the P2PSIP seems to understand what we are NOT doing is RFC 3263. Is it useful to call "Classic SIP" "RFC 3263 SIP"? > 6) I also note that on the goals and milestones, in other charter > changes you have been requesting WGLC dates as well as submission to > IESG dates. Perhaps we should add these. That would be lovely. Thanks, Spencer From hsinnrei at adobe.com Wed Jan 3 09:30:29 2007 From: hsinnrei at adobe.com (Henry Sinnreich) Date: Wed, 3 Jan 2007 06:30:29 -0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141485@namail5.corp.adobe.com> I fully agree with the proposed text. Thanks Cullen for all the work done over the holidays! Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Cullen Jennings Sent: Tuesday, January 02, 2007 3:33 PM To: P2P-SIP Subject: [p2p-sip] P2PSIP Charter ready for IESG I want to put the charter on the IESG agenda this thursday so we can discuss it on the next IES call on Jan 11th. I have talked about it with a lot of people and I would like to make a few trivial changes and one significant change. The significant change is adding text along lines of: The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. I think this text is consistent with the current thinking of the folks on this list and what we discussed in the BOF. If people are OK with this, I would like to include this is the version I send to the IESG. The version that goes to IESG next week is not final. Typically after going to IESG it will be sent out for IETF wide comment and we adjust the text at this point. After this it goes back to the IESG for approval as a WG. I have attached a ascii version of my current working version of the charter along with a word document that have change tracking turned on. Please have a look and check that this includes all the latest changes. Thanks, Cullen From michael.slavitch at e2exchange.com Wed Jan 3 10:26:16 2007 From: michael.slavitch at e2exchange.com (Michael Slavitch) Date: Wed, 3 Jan 2007 10:26:16 -0500 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> References: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> Message-ID: Excellent work Cullen. Onwards and upwards. On 1/2/07, Cullen Jennings wrote: > > I want to put the charter on the IESG agenda this thursday so we can > discuss it on the next IES call on Jan 11th. > > I have talked about it with a lot of people and I would like to make > a few trivial changes and one significant change. The significant > change is adding text along lines of: > > The initial work will assume the existence of some enrollment process > that > provides a unique user name, credentials, and an initial set of > bootstrap nodes > if that is required by the protocols. Developing a non-centralized > enrollment > process is not in scope. > > I think this text is consistent with the current thinking of the > folks on this list and what we discussed in the BOF. If people are OK > with this, I would like to include this is the version I send to the > IESG. The version that goes to IESG next week is not final. Typically > after going to IESG it will be sent out for IETF wide comment and we > adjust the text at this point. After this it goes back to the IESG > for approval as a WG. > > I have attached a ascii version of my current working version of the > charter along with a word document that have change tracking turned > on. Please have a look and check that this includes all the latest > changes. > > Thanks, Cullen > > > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070103/79e13a5f/attachment.html From eunsooshim at gmail.com Wed Jan 3 10:50:49 2007 From: eunsooshim at gmail.com (Eunsoo Shim) Date: Wed, 3 Jan 2007 10:50:49 -0500 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> References: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> Message-ID: <7b683f3f0701030750h52b0078aq205f40809c12b834@mail.gmail.com> The revised charter is very good. Thanks, Cullen. Just one minor comment. The text in the charter: "P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it located users and resources." "located users" is a typo, I guess. It should be "to locate users". "do not store information in the overlay" sounds a little bit confusing. I guess you meant "do not store information for other nodes of the overlay". I think routing messages for other nodes in the overlay is more important difference between peers and clients. So I'd like to suggest the following. "P2PSIP clients differ from P2PSIP peers primarily in that they do not route lookup and overlay maintenance messages, but only use the overlay to locate users and resources." Well, if there is a different opinion about whether routing is more importance difference than storing information, I would not mind having 'storing information' mentioned as the primary difference. It is not worth a round of discussion. Thanks. Eunsoo On 1/2/07, Cullen Jennings wrote: > > I want to put the charter on the IESG agenda this thursday so we can > discuss it on the next IES call on Jan 11th. > > I have talked about it with a lot of people and I would like to make > a few trivial changes and one significant change. The significant > change is adding text along lines of: > > The initial work will assume the existence of some enrollment process > that > provides a unique user name, credentials, and an initial set of > bootstrap nodes > if that is required by the protocols. Developing a non-centralized > enrollment > process is not in scope. > > I think this text is consistent with the current thinking of the > folks on this list and what we discussed in the BOF. If people are OK > with this, I would like to include this is the version I send to the > IESG. The version that goes to IESG next week is not final. Typically > after going to IESG it will be sent out for IETF wide comment and we > adjust the text at this point. After this it goes back to the IESG > for approval as a WG. > > I have attached a ascii version of my current working version of the > charter along with a word document that have change tracking turned > on. Please have a look and check that this includes all the latest > changes. > > Thanks, Cullen > > > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070103/f6f16aa3/attachment-0001.html From mlepinski at bbn.com Wed Jan 3 12:44:43 2007 From: mlepinski at bbn.com (Matt Lepinski) Date: Wed, 03 Jan 2007 12:44:43 -0500 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <7b683f3f0701030750h52b0078aq205f40809c12b834@mail.gmail.com> References: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> <7b683f3f0701030750h52b0078aq205f40809c12b834@mail.gmail.com> Message-ID: <459BEB8B.6090902@bbn.com> I agree with Eunsoo that the phrase: "do not store information in the overlay" is confusing (with regards to the differences between clients and peers). I like Eunsoo's proposal: "P2PSIP clients differ from P2PSIP peers primarily in that they do not route lookup and overlay maintenance messages, but only use the overlay to locate users and resources." Or perhaps: "P2PSIP clients differ from P2PSIP peers in that they use the overly only to locate users and resources. In particular, they do not store information for other nodes of the overlay, and they do not route lookup and overlay maintenance messages." - Matt Lepinski :-> Eunsoo Shim wrote: > The revised charter is very good. Thanks, Cullen. > > Just one minor comment. > > The text in the charter: > "P2PSIP clients differ from P2PSIP peers primarily in that they do not > store information in the overlay, but only use it located users and > resources." > > "located users" is a typo, I guess. It should be "to locate users". > "do not store information in the overlay" sounds a little bit > confusing. I guess you meant "do not store information for other nodes > of the overlay". > I think routing messages for other nodes in the overlay is more > important difference between peers and clients. > > So I'd like to suggest the following. > "P2PSIP clients differ from P2PSIP peers primarily in that they do not > route lookup and overlay maintenance messages, but only use the > overlay to locate users and resources." > > Well, if there is a different opinion about whether routing is more > importance difference than storing information, I would not mind > having 'storing information' mentioned as the primary difference. It > is not worth a round of discussion. > > Thanks. > > Eunsoo > > > On 1/2/07, *Cullen Jennings* > wrote: > > I want to put the charter on the IESG agenda this thursday so we can > discuss it on the next IES call on Jan 11th. > > I have talked about it with a lot of people and I would like to make > a few trivial changes and one significant change. The significant > change is adding text along lines of: > > The initial work will assume the existence of some enrollment process > that > provides a unique user name, credentials, and an initial set of > bootstrap nodes > if that is required by the protocols. Developing a non-centralized > enrollment > process is not in scope. > > I think this text is consistent with the current thinking of the > folks on this list and what we discussed in the BOF. If people are OK > with this, I would like to include this is the version I send to the > IESG. The version that goes to IESG next week is not final. Typically > after going to IESG it will be sent out for IETF wide comment and we > adjust the text at this point. After this it goes back to the IESG > for approval as a WG. > > I have attached a ascii version of my current working version of the > charter along with a word document that have change tracking turned > on. Please have a look and check that this includes all the latest > changes. > > Thanks, Cullen > > > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > >------------------------------------------------------------------------ > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From fluffy at cisco.com Wed Jan 3 12:49:18 2007 From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 3 Jan 2007 09:49:18 -0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <7b683f3f0701030750h52b0078aq205f40809c12b834@mail.gmail.com> References: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com> <7b683f3f0701030750h52b0078aq205f40809c12b834@mail.gmail.com> Message-ID: <7BBDAD2B-3378-4EE3-A3C9-23CA0A913FE5@cisco.com> Thanks everyone for good comments - I will try and get an updated copy out tonight. From RADHIKA.R.ROY at saic.com Wed Jan 3 12:51:20 2007 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Wed, 3 Jan 2007 12:51:20 -0500 Subject: [p2p-sip] P2PSIP Charter ready for IESG References: <53BF0D2F-483E-4CCF-92E4-30719E02F706@cisco.com><7b683f3f0701030750h52b0078aq205f40809c12b834@mail.gmail.com> <459BEB8B.6090902@bbn.com> Message-ID: <62D92A9A02BCC845B202323D49A48426E1CF82@0591-ITS-EXMP02.us.saic.com> Matt: Right. The key is that a client does NOT have the "routing" capabilities while a peer does have. This shall be the "key" for differentiation between the two. All others are good, but not so critical. Radhika ________________________________ From: p2p-sip-bounces at cs.columbia.edu on behalf of Matt Lepinski Sent: Wed 1/3/2007 12:44 PM To: P2P-SIP Subject: Re: [p2p-sip] P2PSIP Charter ready for IESG I agree with Eunsoo that the phrase: "do not store information in the overlay" is confusing (with regards to the differences between clients and peers). I like Eunsoo's proposal: "P2PSIP clients differ from P2PSIP peers primarily in that they do not route lookup and overlay maintenance messages, but only use the overlay to locate users and resources." Or perhaps: "P2PSIP clients differ from P2PSIP peers in that they use the overly only to locate users and resources. In particular, they do not store information for other nodes of the overlay, and they do not route lookup and overlay maintenance messages." - Matt Lepinski :-> -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070103/905a8a58/attachment.html From jiang.x.f at huawei.com Wed Jan 3 21:52:17 2007 From: jiang.x.f at huawei.com (JiangXingFeng) Date: Thu, 04 Jan 2007 10:52:17 +0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <7b683f3f0701030750h52b0078aq205f40809c12b834@mail.gmail.com> Message-ID: <000001c72fab$58c1d6c0$7205a40a@china.huawei.com> Excellent work, thanks, Cullen! I agree with Eunsoo that routing is a import difference between peers and clients. Another comment is presented as follows: "This protocol will define how the P2PSIP peers collectively provide for user and resource location in a SIP environment with no or minimal centralized servers." >From the above sentence I guess that in some special situations, some central servers may be needed to put P2PSIP into operation. " This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a peer or client, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users of these peers or clients, without relying on centralized servers. " In this sentence, it says "without relying on centralized servers". I think it is confusing with what the former sentence wants to express. Maybe we should revise it and make them consistent. Regards! -- Jiang XingFeng From fluffy at cisco.com Thu Jan 4 00:20:11 2007 From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 3 Jan 2007 21:20:11 -0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: <000001c72fab$58c1d6c0$7205a40a@china.huawei.com> References: <000001c72fab$58c1d6c0$7205a40a@china.huawei.com> Message-ID: Thanks for careful read - inline.... On Jan 3, 2007, at 6:52 PM, JiangXingFeng wrote: > Excellent work, thanks, Cullen! > > I agree with Eunsoo that routing is a import difference between > peers and > clients. I thought about this long and hard. The definition of a peer and client has been a major source of confusion in many of the discussions. I went back and looked listened to some of the BOF recording and looked at Dean's draft. I think what we have in the charter now is consistent with that and I don't feel confident that if I change the definition of this that it will still represent what everyone means. Basically it has been such a confusing thing, I am afraid to touch it any way at this point in time. The term routing also has a lot of meanings and it is hard to define how the P2P folks use it - we both know what you mean by routing in the overlay network but to many folks in IETF that are not involved with this , the term routing might conjure up visions of how the IP packet gets from a client to a peer which involved layer 3 routing while what you mean is more layer 5. We also have the open questions about if the peers will do "forwarding" style routing or "redirect" style routing which many people do not consider routing at all. So what I am getting at here is I agree with you Eunsoo that given what you mean by routing, peers will do it and clients probably won't, but I don't want to add that text to charter right now because I think it will cause more confusion than clarification. > > Another comment is presented as follows: > "This protocol will define how the P2PSIP peers collectively > provide for > user and resource location in a SIP environment with no or minimal > centralized servers." > From the above sentence I guess that in some special situations, some > central servers may be needed to put P2PSIP into operation. > > " This document will address how the protocols defined above, along > with > existing IETF protocols, can be used to produce systems to locate > a peer or > client, identify appropriate resources to facilitate > communications (for > example media relays), and establish communications between the > users of > these peers or clients, without relying on centralized servers. " > In this sentence, it says "without relying on centralized > servers". I think > it is confusing with what the former sentence wants to express. > > Maybe we should revise it and make them consistent. I think this somewhat contradicting statement is somewhat deliberate. For some types of systems, we are going to need to have a central enrollment server - and the gateways to traditional SIP systems may also end up being somewhat "central" depending on you definition of "central". So in the first case we leave ourselves wiggle room for this type of thing. But the second paragraph is about the actual overlay protocol that provides the 3263 like functionality. Here we don't want to leave ourselves any wiggle room - we are saying this truly does have to be non centralized. > > Regards! > -- > Jiang XingFeng From fluffy at cisco.com Thu Jan 4 00:28:02 2007 From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 3 Jan 2007 21:28:02 -0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG (take 2) In-Reply-To: <04b001c72ee2$d5f30a70$0202a8c0@Quinthar> References: <04b001c72ee2$d5f30a70$0202a8c0@Quinthar> Message-ID: <6FB3B197-3C92-4E6F-A446-E55121CCA859@cisco.com> Ok here is a updated version of the charter. I think I managed to get everyone's comments in other than a few that I replied to separately on the list. I think this is good enough to go to IESG and we can still revise it before the final version is done. Thanks, everyone (and if you catch any outrageous typo's let me know so I can fix them - I currently have either too little coffee or too little sleep :-) Thanks, Cullen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: P2PSIP-Charter-Jan3.txt Url: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070104/72b6fcc0/P2PSIP-Charter-Jan3-0001.txt -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: P2PSIP-charter-Jan3.doc Type: application/octet-stream Size: 37888 bytes Desc: not available Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070104/72b6fcc0/P2PSIP-charter-Jan3-0001.obj From dbarrett at quinthar.com Thu Jan 4 00:51:43 2007 From: dbarrett at quinthar.com (David Barrett) Date: Wed, 3 Jan 2007 21:51:43 -0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG (take 2) In-Reply-To: <6FB3B197-3C92-4E6F-A446-E55121CCA859@cisco.com> Message-ID: <026d01c72fc4$6ae27530$230aa8c0@Quinthar> Looks great, thanks! > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > bounces at cs.columbia.edu] On Behalf Of Cullen Jennings > Sent: Wednesday, January 03, 2007 9:28 PM > To: P2P-SIP > Subject: Re: [p2p-sip] P2PSIP Charter ready for IESG (take 2) > > > Ok here is a updated version of the charter. I think I managed to get > everyone's comments in other than a few that I replied to separately > on the list. I think this is good enough to go to IESG and we can > still revise it before the final version is done. Thanks, everyone > (and if you catch any outrageous typo's let me know so I can fix them > - I currently have either too little coffee or too little sleep :-) > > Thanks, Cullen > From jiang.x.f at huawei.com Thu Jan 4 00:57:09 2007 From: jiang.x.f at huawei.com (JiangXingFeng) Date: Thu, 04 Jan 2007 13:57:09 +0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG In-Reply-To: Message-ID: <000001c72fc5$2ca126d0$7205a40a@china.huawei.com> Thanks for your explanations which are very convincing to me! Maybe it is the best expressions in Charter, since there are a few technology details are not deterministic at current stage. Regards! -- Jiang XingFeng > -----Original Message----- > From: Cullen Jennings [mailto:fluffy at cisco.com] > Sent: Thursday, January 04, 2007 1:20 PM > To: JiangXingFeng > Cc: 'Eunsoo Shim'; 'P2P-SIP' > Subject: Re: [p2p-sip] P2PSIP Charter ready for IESG > > > Thanks for careful read - inline.... > > On Jan 3, 2007, at 6:52 PM, JiangXingFeng wrote: > > > Excellent work, thanks, Cullen! > > > > I agree with Eunsoo that routing is a import difference between > > peers and > > clients. > > > I thought about this long and hard. The definition of a peer and > client has been a major source of confusion in many of the > discussions. I went back and looked listened to some of the BOF > recording and looked at Dean's draft. I think what we have in the > charter now is consistent with that and I don't feel confident that > if I change the definition of this that it will still represent what > everyone means. Basically it has been such a confusing thing, I am > afraid to touch it any way at this point in time. The term routing > also has a lot of meanings and it is hard to define how the P2P folks > use it - we both know what you mean by routing in the overlay network > but to many folks in IETF that are not involved with this , the term > routing might conjure up visions of how the IP packet gets from a > client to a peer which involved layer 3 routing while what you mean > is more layer 5. We also have the open questions about if the peers > will do "forwarding" style routing or "redirect" style routing which > many people do not consider routing at all. > > So what I am getting at here is I agree with you Eunsoo that given > what you mean by routing, peers will do it and clients probably > won't, but I don't want to add that text to charter right now because > I think it will cause more confusion than clarification. > > > > > > Another comment is presented as follows: > > "This protocol will define how the P2PSIP peers collectively > > provide for > > user and resource location in a SIP environment with no or minimal > > centralized servers." > > From the above sentence I guess that in some special situations, some > > central servers may be needed to put P2PSIP into operation. > > > > " This document will address how the protocols defined above, along > > with > > existing IETF protocols, can be used to produce systems to locate > > a peer or > > client, identify appropriate resources to facilitate > > communications (for > > example media relays), and establish communications between the > > users of > > these peers or clients, without relying on centralized servers. " > > In this sentence, it says "without relying on centralized > > servers". I think > > it is confusing with what the former sentence wants to express. > > > > Maybe we should revise it and make them consistent. > > I think this somewhat contradicting statement is somewhat deliberate. > For some types of systems, we are going to need to have a central > enrollment server - and the gateways to traditional SIP systems may > also end up being somewhat "central" depending on you definition of > "central". So in the first case we leave ourselves wiggle room for > this type of thing. But the second paragraph is about the actual > overlay protocol that provides the 3263 like functionality. Here we > don't want to leave ourselves any wiggle room - we are saying this > truly does have to be non centralized. > > > > > Regards! > > -- > > Jiang XingFeng From jean-francois.wauthy at alcatel-lucent.fr Thu Jan 4 05:54:47 2007 From: jean-francois.wauthy at alcatel-lucent.fr (=?ISO-8859-1?Q?Jean-Fran=E7ois_Wauthy?=) Date: Thu, 04 Jan 2007 11:54:47 +0100 Subject: [p2p-sip] P2PSIP Charter ready for IESG (take 2) In-Reply-To: <6FB3B197-3C92-4E6F-A446-E55121CCA859@cisco.com> References: <04b001c72ee2$d5f30a70$0202a8c0@Quinthar> <6FB3B197-3C92-4E6F-A446-E55121CCA859@cisco.com> Message-ID: <459CDCF7.8040304@alcatel-lucent.fr> See inline for comments Cullen Jennings a ?crit : > that allow _anonynimaztion_ of the IP address of P2PSIP peers by using > approaches such as onion routing. > I think that may be you fell asleep on your keyboard when you typed 'anonymization' :-D > Goals and Milestones: > > (Note dates our very draft > > Jul 2007 WGLC of P2PSIP overview document > Sep 2007 Submit P2PSIP overview document to the IESG (Informational) > > Jan 2008 WGLC of P2PSIP Client Protocol document > Mar 2008 Submit P2PSIP Client Protocol document to the IESG (PS) > > Jul 2008 WGLC of P2PSIP Peer Protocol document > Sep 2008 Submit P2PSIP Peer Protocol document to the IESG (PS) > > Apr 2009 WGLC of P2PSIP usage document > May 2009 Submit P2PSIP usage document to the IESG (BCP) > Could you tell me why you put the now optional P2PSIP Client Protocol document milestones before the 'mandatory' P2PSIP Peer Protocol document ones ? This doesn't reflect the order of the primary tasks developed in the charter either. Regards, Jean-Fran?ois Wauthy From RADHIKA.R.ROY at saic.com Thu Jan 4 10:53:48 2007 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Thu, 4 Jan 2007 10:53:48 -0500 Subject: [p2p-sip] P2PSIP Charter ready for IESG References: <000001c72fab$58c1d6c0$7205a40a@china.huawei.com> Message-ID: <62D92A9A02BCC845B202323D49A48426E1CF8D@0591-ITS-EXMP02.us.saic.com> Cullen: It may be OK not to modify the client and peer definition related to routing for now in the charter. However, when we say "routing" in the context of p2p-SIP, it is in the p2p-SIP layer (i.e., application layer). Radhika ________________________________ From: p2p-sip-bounces at cs.columbia.edu on behalf of Cullen Jennings Sent: Thu 1/4/2007 12:20 AM To: JiangXingFeng Cc: 'P2P-SIP' Subject: Re: [p2p-sip] P2PSIP Charter ready for IESG Thanks for careful read - inline.... On Jan 3, 2007, at 6:52 PM, JiangXingFeng wrote: > Excellent work, thanks, Cullen! > > I agree with Eunsoo that routing is a import difference between > peers and > clients. I thought about this long and hard. The definition of a peer and client has been a major source of confusion in many of the discussions. I went back and looked listened to some of the BOF recording and looked at Dean's draft. I think what we have in the charter now is consistent with that and I don't feel confident that if I change the definition of this that it will still represent what everyone means. Basically it has been such a confusing thing, I am afraid to touch it any way at this point in time. The term routing also has a lot of meanings and it is hard to define how the P2P folks use it - we both know what you mean by routing in the overlay network but to many folks in IETF that are not involved with this , the term routing might conjure up visions of how the IP packet gets from a client to a peer which involved layer 3 routing while what you mean is more layer 5. We also have the open questions about if the peers will do "forwarding" style routing or "redirect" style routing which many people do not consider routing at all. So what I am getting at here is I agree with you Eunsoo that given what you mean by routing, peers will do it and clients probably won't, but I don't want to add that text to charter right now because I think it will cause more confusion than clarification. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070104/499892c8/attachment.html From fluffy at cisco.com Thu Jan 4 13:10:52 2007 From: fluffy at cisco.com (Cullen Jennings) Date: Thu, 4 Jan 2007 10:10:52 -0800 Subject: [p2p-sip] P2PSIP Charter ready for IESG (take 2) In-Reply-To: <459CDCF7.8040304@alcatel-lucent.fr> References: <04b001c72ee2$d5f30a70$0202a8c0@Quinthar> <6FB3B197-3C92-4E6F-A446-E55121CCA859@cisco.com> <459CDCF7.8040304@alcatel-lucent.fr> Message-ID: Oh my - thank you ... inline .... On Jan 4, 2007, at 2:54 AM, Jean-Fran?ois Wauthy wrote: > See inline for comments > > Cullen Jennings a ?crit : >> that allow _anonynimaztion_ of the IP address of P2PSIP peers by >> using >> approaches such as onion routing. >> > I think that may be you fell asleep on your keyboard when you typed > 'anonymization' :-D yes >> Goals and Milestones: >> >> (Note dates our very draft >> >> Jul 2007 WGLC of P2PSIP overview document Sep 2007 Submit P2PSIP >> overview document to the IESG (Informational) >> >> Jan 2008 WGLC of P2PSIP Client Protocol document >> Mar 2008 Submit P2PSIP Client Protocol document to the IESG (PS) >> >> Jul 2008 WGLC of P2PSIP Peer Protocol document >> Sep 2008 Submit P2PSIP Peer Protocol document to the IESG (PS) >> >> Apr 2009 WGLC of P2PSIP usage document May 2009 Submit P2PSIP >> usage document to the IESG (BCP) >> > Could you tell me why you put the now optional P2PSIP Client > Protocol document milestones before the 'mandatory' P2PSIP Peer > Protocol document ones ? This doesn't reflect the order of the > primary tasks developed in the charter either. I don't know what I was typing - I meant to put the Peer protocol before the Client protocol since it will be easier to decide if the Client protocol is a syntactic subset of the Peer protocol or not once we have an idea what the Peer protocol looks like. I view all these dates as random numbers pulled out of thin air and hope the WG would refine them once they got going so we should not get too worked up about the dates right now but I agree I got the order backwards. > > Regards, > > Jean-Fran?ois Wauthy From fluffy at cisco.com Thu Jan 4 13:52:33 2007 From: fluffy at cisco.com (Cullen Jennings) Date: Thu, 4 Jan 2007 10:52:33 -0800 Subject: [p2p-sip] Version of P2PSIP Charter send the IESG Message-ID: <3EF07A3C-C66F-43CF-A736-95D05B1E24D1@cisco.com> Peer-to-Peer Session Initiation Protocol (P2PSIP) (Jan 4 Version) Chairs: TBD RAI Area Director(s): Cullen Jennings and Jon Peterson RAI Area Advisor: Cullen Jennings Mailing Lists: General Discussion: p2p-sip at cs.columbia.edu Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/ (Note: mailing list will be moving to ietf) Description of the Working Group: The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP) in settings where the service of establishing and managing sessions is principally handled by a collection of intelligent endpoints, rather than centralized servers as in SIP as currently deployed. A number of cases where such an architecture is desirable have been documented. The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality. Session management, messaging, and presence functions are performed using conventional SIP. This group's primary tasks are to produce: 1. An overview document explaining concepts, terminology, rationale, and illustrative use cases for the remaining work. 2. A proposed standard defining a P2PSIP Peer Protocol. This protocol is used between P2PSIP overlay peers, some of which may be behind NATs. This protocol will define how the P2PSIP peers collectively provide for user and resource location in a SIP environment with no or minimal centralized servers. This protocol may or may not be syntactically based on SIP, a decision to be made by the WG. The group will identify and require one base P2P algorithm (likely a particular Distributed Hash Table (DHT) algorithm), while allowing for additional optional algorithms in the future. 3. Optionally, a proposed standard defining a P2PSIP Client Protocol for use by P2PSIP clients, some of which may be behind NATs. This protocol will define how the P2PSIP clients query and/or modify, the resource location information of the overlay. While clearly a logical subset of the P2PSIP Protocol, the WG will determine if the P2PSIP Client Protocol is a syntactic subset of the P2PSIP Peer Protocol, and whether the P2PSIP Client Protocol builds on the SIP protocol. 4. A usage document. This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a P2PSIP peer or client, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users of these P2PSIP peers or clients, without relying on centralized servers. Additionally, the document will explain how P2PSIP and conventional SIP entities can interoperate. The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. The work planned for the P2PSIP working group is distinct from, but requires close participation with other IETF WGs, particularly SIP, SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the baseline SIP behavior, define a new version of SIP, or attempt to produce a parallel protocol for session establishment. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group using the SIP change process (RFC 3427). Similarly, existing tools developed in the BEHAVE and MMUSIC groups will be used for NAT traversal, with extensions or changes desired to support P2PSIP presented to the BEHAVE or MMUSIC working groups. The working group will assume that NATs and firewalls exist in the Internet, and will ensure that the protocols produced work in their presence as much as possible. "Similarly, the WG will avoid making protocol design decisions that would preclude the creation of anonymous communications systems using techniques such as onion routing to conceal the IP addresses of P2PSIP peers. The following topics are excluded from the Working Group's scope: 1. Issues specific to applications other than locating users and resources for SIP-based communications and presence. 2. Solving "research" type questions related to P2PSIP or P2P in general. The WG will instead forward such work to the IRTF P2PRG or other RG as appropriate. Examples include fully distributed schemes for assuring unique user identities and the development of P2P-based replacements for DNS. 3. Locating resources based on something other than URIs. In other words, arbitrary search of attributes is out of scope, but locating resources based on their URIs is in scope. Using URIs need not imply using the DNS or having a record in the DNS for the URI. 4. Multicast and dynamic DNS based approaches as the core lookup mechanism for locating users and resources. Approaches based on these technologies may be reasonable ways to solve similar problems but that is not the focus of this WG. These techniques may be in-scope for locating bootstrap peers/servers or for interoperation with conventional SIP. Goals and Milestones: (Note: dates are very draft) Jul 2007 WGLC of P2PSIP overview document Sep 2007 Submit P2PSIP overview document to the IESG (Informational) Jan 2008 WGLC of P2PSIP Peer Protocol document Mar 2008 Submit P2PSIP Peer Protocol document to the IESG (PS) Jul 2008 WGLC of P2PSIP Client Protocol document Aug 2008 Submit P2PSIP Client Protocol document to the IESG (PS) Apr 2009 WGLC of P2PSIP usage document May 2009 Submit P2PSIP usage document to the IESG (BCP) From br at brianrosen.net Thu Jan 4 14:24:29 2007 From: br at brianrosen.net (Brian Rosen) Date: Thu, 4 Jan 2007 14:24:29 -0500 Subject: [p2p-sip] Version of P2PSIP Charter send the IESG In-Reply-To: <3EF07A3C-C66F-43CF-A736-95D05B1E24D1@cisco.com> Message-ID: <021101c73035$f62a3670$640fa8c0@cis.neustar.com> Looks good Brian > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > bounces at cs.columbia.edu] On Behalf Of Cullen Jennings > Sent: Thursday, January 04, 2007 1:53 PM > To: P2P-SIP > Subject: [p2p-sip] Version of P2PSIP Charter send the IESG > > Peer-to-Peer Session Initiation Protocol (P2PSIP) (Jan 4 Version) > > Chairs: TBD > > RAI Area Director(s): Cullen Jennings and Jon Peterson > > RAI Area Advisor: Cullen Jennings > > Mailing Lists: General Discussion: p2p-sip at cs.columbia.edu > Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/ > (Note: mailing list will be moving to ietf) > > > Description of the Working Group: > > The Peer-to-Peer (P2P) Session Initiation Protocol working group > (P2PSIP WG) is chartered to develop protocols and mechanisms for the > use of the Session Initiation Protocol (SIP) in settings where the > service of establishing and managing sessions is principally handled > by a collection of intelligent endpoints, rather than centralized > servers as in SIP as currently deployed. A number of cases where such > an architecture is desirable have been documented. > > The work focuses on collections of nodes called "P2PSIP peers" and > "P2PSIP clients". P2PSIP peers manifest a distributed namespace in > which overlay users are identified and provides mechanisms for > locating users or resources within the P2PSIP overlay. P2PSIP clients > differ from P2PSIP peers primarily in that they do not store > information in the overlay, but only use it to locate users and > resources. P2PSIP clients and peers use the resolution services of the > peers as an alternative to the SIP discovery process of RFC 3263. In > this way, P2PSIP offers an alternative mechanism for determining the > correct destination for SIP requests. The working group's initial > charter scope will be to produce protocols to enable this alternate > mechanism for RFC 3263 functionality. Session management, messaging, > and presence functions are performed using conventional SIP. > > This group's primary tasks are to produce: > > 1. An overview document explaining concepts, terminology, rationale, > and illustrative use cases for the remaining work. > 2. A proposed standard defining a P2PSIP Peer Protocol. This protocol > is used between P2PSIP overlay peers, some of which may be behind > NATs. This protocol will define how the P2PSIP peers collectively > provide for user and resource location in a SIP environment with no > or minimal centralized servers. This protocol may or may not be > syntactically based on SIP, a decision to be made by the WG. The > group will identify and require one base P2P algorithm (likely a > particular Distributed Hash Table (DHT) algorithm), while allowing > for additional optional algorithms in the future. > > 3. Optionally, a proposed standard defining a P2PSIP Client Protocol > for use by P2PSIP clients, some of which may be behind NATs. This > protocol will define how the P2PSIP clients query and/or modify, > the resource location information of the overlay. While clearly a > logical subset of the P2PSIP Protocol, the WG will determine if the > P2PSIP Client Protocol is a syntactic subset of the P2PSIP Peer > Protocol, and whether the P2PSIP Client Protocol builds on the SIP > protocol. > > 4. A usage document. This document will address how the protocols > defined above, along with existing IETF protocols, can be used to > produce systems to locate a P2PSIP peer or client, identify > appropriate resources to facilitate communications (for example > media relays), and establish communications between the users of > these P2PSIP peers or clients, without relying on centralized > servers. Additionally, the document will explain how P2PSIP and > conventional SIP entities can interoperate. > > The initial work will assume the existence of some enrollment process > that provides a unique user name, credentials, and an initial set of > bootstrap nodes if that is required by the protocols. Developing a > non-centralized enrollment process is not in scope. > > The work planned for the P2PSIP working group is distinct from, but > requires close participation with other IETF WGs, particularly SIP, > SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the > baseline SIP behavior, define a new version of SIP, or attempt to > produce a parallel protocol for session establishment. If the group > determines that any capabilities requiring an extension to SIP are > needed, the group will seek to define such extensions within the SIP > working group using the SIP change process (RFC 3427). Similarly, > existing tools developed in the BEHAVE and MMUSIC groups will be used > for NAT traversal, with extensions or changes desired to support > P2PSIP presented to the BEHAVE or MMUSIC working groups. > > The working group will assume that NATs and firewalls exist in the > Internet, and will ensure that the protocols produced work in their > presence as much as possible. "Similarly, the WG will avoid making > protocol design decisions that would preclude the creation of > anonymous communications systems using techniques such as onion > routing to conceal the IP addresses of P2PSIP peers. > > The following topics are excluded from the Working Group's scope: > > 1. Issues specific to applications other than locating users and > resources for SIP-based communications and presence. > > 2. Solving "research" type questions related to P2PSIP or P2P in > general. The WG will instead forward such work to the IRTF P2PRG or > other RG as appropriate. Examples include fully distributed schemes > for assuring unique user identities and the development of > P2P-based replacements for DNS. > > 3. Locating resources based on something other than URIs. In other > words, arbitrary search of attributes is out of scope, but locating > resources based on their URIs is in scope. Using URIs need not > imply using the DNS or having a record in the DNS for the URI. > > 4. Multicast and dynamic DNS based approaches as the core lookup > mechanism for locating users and resources. Approaches based on > these technologies may be reasonable ways to solve similar problems > but that is not the focus of this WG. These techniques may be > in-scope for locating bootstrap peers/servers or for interoperation > with conventional SIP. > > Goals and Milestones: > > (Note: dates are very draft) > > Jul 2007 WGLC of P2PSIP overview document > Sep 2007 Submit P2PSIP overview document to the IESG (Informational) > > Jan 2008 WGLC of P2PSIP Peer Protocol document > Mar 2008 Submit P2PSIP Peer Protocol document to the IESG (PS) > > Jul 2008 WGLC of P2PSIP Client Protocol document > Aug 2008 Submit P2PSIP Client Protocol document to the IESG (PS) > > Apr 2009 WGLC of P2PSIP usage document > May 2009 Submit P2PSIP usage document to the IESG (BCP) > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From frank.shearar at angband.za.org Fri Jan 5 06:14:39 2007 From: frank.shearar at angband.za.org (Frank Shearar) Date: Fri, 5 Jan 2007 13:14:39 +0200 Subject: [p2p-sip] Nit: Re: Version of P2PSIP Charter send the IESG References: <3EF07A3C-C66F-43CF-A736-95D05B1E24D1@cisco.com> Message-ID: <05bf01c730ba$b3e0e860$0600000a@wsfrank> "Cullen Jennings" wrote: > The working group will assume that NATs and firewalls exist in the > Internet, and will ensure that the protocols produced work in their > presence as much as possible. "Similarly, the WG will avoid making > protocol design decisions that would preclude the creation of > anonymous communications systems using techniques such as onion > routing to conceal the IP addresses of P2PSIP peers. The " looks like a typo. Other than that, it looks good! frank From jani.hautakorpi at ericsson.com Wed Jan 10 10:06:07 2007 From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF)) Date: Wed, 10 Jan 2007 17:06:07 +0200 Subject: [p2p-sip] Comments to draft-singh-p2p-sip-00 Message-ID: <45A500DF.1060600@ericsson.com> Hi all, I read your draft draft-singh-p2p-sip-00 and I especially liked sections 1-3 and 6. I felt that the section 4 and 5 are still quite abstract, although they contain fairly good ideas. Please check my inline comments from: http://users.piuha.net/jantzgu/temp/draft-singh-p2p-sip-00-commented.html -- Regards, Jani Hautakorpi From jani.hautakorpi at ericsson.com Wed Jan 10 10:10:05 2007 From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF)) Date: Wed, 10 Jan 2007 17:10:05 +0200 Subject: [p2p-sip] Comments to draft-baset-sipping-p2pcommon-00 Message-ID: <45A501CD.5080308@ericsson.com> Hi all, I read your draft draft-baset-sipping-p2pcommon-00 and I didn't quite get what is the long-term goal of this draft? At the moment it really doesn't contain a lot of information that wouldn't already be documented in draft-singh-p2p-sip-00. However, I liked the title of the draft "A protocol for Implementing Various DHT Algorithms", because I personally believe that a common protocol for different DHT algorithm would be useful (and feasible). Please check my inline comments from: http://users.piuha.net/jantzgu/temp/draft-baset-sipping-p2pcommon-00-commented.html -- Regards, Jani Hautakorpi From 2007 at shudo.net Wed Jan 10 12:10:53 2007 From: 2007 at shudo.net (Kazuyuki Shudo) Date: Thu, 11 Jan 2007 02:10:53 +0900 (JST) Subject: [p2p-sip] Comments to draft-baset-sipping-p2pcommon-00 In-Reply-To: <45A501CD.5080308@ericsson.com> References: <45A501CD.5080308@ericsson.com> Message-ID: <20070111.021053.608446308.shudo@utagoe.com> Hi all, I have recently subscribe to this p2p-sip list and started looking over what is ongoing. > From: "Jani Hautakorpi (JO/LMF)" > Date: Wed, 10 Jan 2007 17:10:05 +0200 > I read your draft draft-baset-sipping-p2pcommon-00 and (stuff deleted) > However, I liked the title of the draft "A protocol for Implementing > Various DHT Algorithms", because I personally believe that a common > protocol for different DHT algorithm would be useful (and feasible). Let me introduce related software. Overlay Weaver implements multiple lookup algorithms such as Chord, Kademlia, Koorde, Pastry and Tapestry. Three algorithms (Chord, Pastry and Kademlia) which the I-D focuses are included. Overlay Weaver: An Overlay Construction Toolkit http://overlayweaver.sourceforge.net/ Overlay Weaver supports parallel lookups with Kademlia in addition to sequential lookups, and both iterative and recursive lookups. It implements multiple service layers, DHT and application-level/layer multipcast (ALM) over a routing layer while the I-D focues on DHT. The protocol is algorithm-independent, but dependent on lookup style (recursive or iterative). A message is serialized Java objects and the wire format of a message has not been designed, but it is definitely possible. > Please check my inline comments from: > > http://users.piuha.net/jantzgu/temp/draft-baset-sipping-p2pcommon-00-commented.html I will have comments by closer look based on the experience in development of Overlay Weaver. A few of them are the followings: Strictly speaking, distance function for Chord is not (b - a) mod 2^M. The distance should be 2^M, not 0 in case that b = a. In some algorithms, distance function is not requied to perform lookups. For example, lookup algorithm of Tapestry is described purely in algorithmic. Regards, Kazuyuki Shudo 2007 at shudo.net http://www.shudo.net/ From hsinnrei at adobe.com Wed Jan 10 16:21:08 2007 From: hsinnrei at adobe.com (Henry Sinnreich) Date: Wed, 10 Jan 2007 13:21:08 -0800 Subject: [p2p-sip] Comments to draft-baset-sipping-p2pcommon-00 In-Reply-To: <45A501CD.5080308@ericsson.com> Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D221414E8@namail5.corp.adobe.com> I also like the approach and as mentioned, Bamboo/openDHT should be included as well. Because the proximity neighbor selection of Bamboo can be based on latency, it is the most preferable IMHO. Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Jani Hautakorpi (JO/LMF) Sent: Wednesday, January 10, 2007 7:10 AM To: salman at cs.columbia.edu; hgs at cs.columbia.edu; eunsoo at research.panasonic.com Cc: p2p-sip at cs.columbia.edu Subject: [p2p-sip] Comments to draft-baset-sipping-p2pcommon-00 Hi all, I read your draft draft-baset-sipping-p2pcommon-00 and I didn't quite get what is the long-term goal of this draft? At the moment it really doesn't contain a lot of information that wouldn't already be documented in draft-singh-p2p-sip-00. However, I liked the title of the draft "A protocol for Implementing Various DHT Algorithms", because I personally believe that a common protocol for different DHT algorithm would be useful (and feasible). Please check my inline comments from: http://users.piuha.net/jantzgu/temp/draft-baset-sipping-p2pcommon-00-com mented.html -- Regards, Jani Hautakorpi _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From fluffy at cisco.com Thu Jan 11 14:08:01 2007 From: fluffy at cisco.com (Cullen Jennings) Date: Thu, 11 Jan 2007 11:08:01 -0800 Subject: [p2p-sip] IESG status update ... Message-ID: <157AC873-576B-4495-8727-6BC6C8258274@cisco.com> The IESG just approved this charter to go out for IETF wide review. So the next step is the charter will get an IETF Last Call and the IESG will review the comments and decide if they approve the the WG or not. During this time, we will need to make some changes to the charter. Sam has pointed out that we have almost no security issues mentioned in the charter. We will need to fix this before it goes back to the IESG. Cullen From philip_matthews at magma.ca Thu Jan 11 15:33:14 2007 From: philip_matthews at magma.ca (Philip Matthews) Date: Thu, 11 Jan 2007 15:33:14 -0500 Subject: [p2p-sip] IESG status update ... In-Reply-To: <157AC873-576B-4495-8727-6BC6C8258274@cisco.com> References: <157AC873-576B-4495-8727-6BC6C8258274@cisco.com> Message-ID: Cullen: In your opinion, based on the IESG discussion, does the charter need to: 1) List a few security problems that need to be solved, OR 2) Describe, at some level, the security that a P2PSIP system needs to provide? - Philip On 11-Jan-07, at 14:08 , Cullen Jennings wrote: > > The IESG just approved this charter to go out for IETF wide review. > So the next step is the charter will get an IETF Last Call and the > IESG will review the comments and decide if they approve the the WG > or not. > > During this time, we will need to make some changes to the charter. > Sam has pointed out that we have almost no security issues mentioned > in the charter. We will need to fix this before it goes back to the > IESG. > > Cullen > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From salman at cs.columbia.edu Mon Jan 15 19:07:05 2007 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Mon, 15 Jan 2007 19:07:05 -0500 (EST) Subject: [p2p-sip] Comments to draft-baset-sipping-p2pcommon-00 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D221414E8@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D221414E8@namail5.corp.adobe.com> Message-ID: Thanks. We are in the process of revising the draft and an updated version will be made available soon. Bamboo can be considered an offshoot of Pastry. The purpose of including the description of DHT algorithms is two fold: 1) to highlight commanalities among various DHTs 2) to show that multiple DHT algorithms can be implemented by one protocol. Regards, Salman On Wed, 10 Jan 2007, Henry Sinnreich wrote: > I also like the approach and as mentioned, Bamboo/openDHT should be > included as well. > > Because the proximity neighbor selection of Bamboo can be based on > latency, it is the most preferable IMHO. > > Henry > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Jani Hautakorpi > (JO/LMF) > Sent: Wednesday, January 10, 2007 7:10 AM > To: salman at cs.columbia.edu; hgs at cs.columbia.edu; > eunsoo at research.panasonic.com > Cc: p2p-sip at cs.columbia.edu > Subject: [p2p-sip] Comments to draft-baset-sipping-p2pcommon-00 > > Hi all, > > I read your draft draft-baset-sipping-p2pcommon-00 and I didn't quite > get what is the long-term goal of this draft? At the moment it really > doesn't contain a lot of information that wouldn't already be documented > in draft-singh-p2p-sip-00. > > However, I liked the title of the draft "A protocol for Implementing > Various DHT Algorithms", because I personally believe that a common > protocol for different DHT algorithm would be useful (and feasible). > Please check my inline comments from: > > http://users.piuha.net/jantzgu/temp/draft-baset-sipping-p2pcommon-00-com > mented.html > > > -- > Regards, > Jani Hautakorpi > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From fluffy at cisco.com Mon Jan 15 22:16:35 2007 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 15 Jan 2007 19:16:35 -0800 Subject: [p2p-sip] Security update for charter References: Message-ID: <21520B56-B8AA-490F-B045-027E8DE07915@cisco.com> While this IETF LC of the charter is happening, I would like to sort out a few updates to the charter. Sam Hartman pointed out that we have no mention of security in the charter. We need to fix this and put in some text that outlines what security assumptions we have and what "bar" we will hold this work to. Added EKR as he is the usual security advisor for the RAI WGs and certainly up to speed on P2PSIP. Cullen From lowekamp at cs.wm.edu Mon Jan 15 23:23:15 2007 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Mon, 15 Jan 2007 23:23:15 -0500 Subject: [p2p-sip] Security update for charter In-Reply-To: <21520B56-B8AA-490F-B045-027E8DE07915@cisco.com> References: <21520B56-B8AA-490F-B045-027E8DE07915@cisco.com> Message-ID: Some thoughts on security: P2PSIP assumes that attackers have the ability to intercept and alter messages. An attacker may be able to compromise one or more individual peers. A P2PSIP overlay must preserve routing integrity in the event of a single compromised peer, or a small percentage of random peers being compromised. If a peer is compromised, the routing protocol must not offer an attacker amplification attacks nor should an attacker be able to insert arbitrary amounts of resource registrations into the overlay to overload the other peers. A P2PSIP protocol may offer varying levels of security to be chosen depending on the type, scale, and vulnerability of a particular deployment. Currently available methods of certificate-chain based security and shared secret security will be chosen for integrity, authentication, and secrecy rather than trying to solve more general distributed security problems. Limited amounts of centralization at enrollment time are likely to be required. Bruce On 1/15/07, Cullen Jennings wrote: > While this IETF LC of the charter is happening, I would like to > sort out a few updates to the charter. > > Sam Hartman pointed out that we have no mention of security in the > charter. We need to fix this and put in some text that outlines what > security assumptions we have and what "bar" we will hold this work > to. Added EKR as he is the usual security advisor for the RAI WGs and > certainly up to speed on P2PSIP. > > Cullen > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From spencer at mcsr-labs.org Mon Jan 15 23:56:30 2007 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Mon, 15 Jan 2007 22:56:30 -0600 Subject: [p2p-sip] Security update for charter References: <21520B56-B8AA-490F-B045-027E8DE07915@cisco.com> Message-ID: <066d01c7392a$b09123a0$6701a8c0@china.huawei.com> I'm not quite sure how to say this, so I'll just say it... The now-expired individual draft on Use Cases described a huge range of deployment scenarios, from global P2PSIP service providers to two devices I own using P2PSIP between those two devices. It seems to me that if the charter is very explicit about security assumptions, it's also very going to be explicit about deployment scenario assumptions, and it seemed to me that we should not be forcing decisions about these assumptions before a working group forms. Discussing the "bar" DOES seem appropriate in the charter. Could we focus on that, saying (much like we say on anonymity) that we must not do things that prevent authentication, confidentiality, etc? I note that even the question of whether request bodies are cryptotransparent to peers that handle requests is still an open issue in the Concepts draft (section 4.5), so I hope I'm not the only one who thinks the working group has some work to do, before security is fully nailed down. Thanks, Spencer > While this IETF LC of the charter is happening, I would like to > sort out a few updates to the charter. > > Sam Hartman pointed out that we have no mention of security in the > charter. We need to fix this and put in some text that outlines what > security assumptions we have and what "bar" we will hold this work > to. Added EKR as he is the usual security advisor for the RAI WGs and > certainly up to speed on P2PSIP. > > Cullen From zhuxian at huawei.com Tue Jan 16 02:20:25 2007 From: zhuxian at huawei.com (zhuxian) Date: Tue, 16 Jan 2007 15:20:25 +0800 Subject: [p2p-sip] Security update for charter In-Reply-To: Message-ID: <000001c7393e$cab602f0$71244e0a@china.huawei.com> I think we may add some sentences about secure peer ID and resource namespace. It's very important in the P2P environment to provide the mechanism about secure peer ID. And the resource location is the main task in the P2PSIP. See inline. >-----Original Message----- >From: p2p-sip-bounces at cs.columbia.edu >[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp >Sent: Tuesday, January 16, 2007 12:23 PM >To: Cullen Jennings >Cc: P2P-SIP >Subject: Re: [p2p-sip] Security update for charter > >Some thoughts on security: > >P2PSIP assumes that attackers have the ability to intercept >and alter messages. An attacker may be able to compromise one >or more individual peers. A P2PSIP overlay must preserve >routing integrity in the event of a single compromised peer, >or a small percentage of random peers being compromised. If a >peer is compromised, the routing protocol must not offer an >attacker amplification attacks nor should an attacker be able >to insert arbitrary amounts of resource registrations into the >overlay to overload the other peers. A P2PSIP overlay must also protect the peer identity namespace and the resource namespace. > A P2PSIP protocol may >offer varying levels of security to be chosen depending on the >type, scale, and vulnerability of a particular deployment. >Currently available methods of certificate-chain based >security and shared secret security will be chosen for >integrity, authentication, and secrecy rather than trying to >solve more general distributed security problems. Limited >amounts of centralization at enrollment time are likely to be required. > >Bruce > > > > >On 1/15/07, Cullen Jennings wrote: >> While this IETF LC of the charter is happening, I would >like to sort >> out a few updates to the charter. >> >> Sam Hartman pointed out that we have no mention of security in the >> charter. We need to fix this and put in some text that outlines what >> security assumptions we have and what "bar" we will hold >this work to. >> Added EKR as he is the usual security advisor for the RAI WGs and >> certainly up to speed on P2PSIP. >> >> Cullen >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From vkg at alcatel-lucent.com Tue Jan 16 15:03:03 2007 From: vkg at alcatel-lucent.com (Vijay K. Gurbani) Date: Tue, 16 Jan 2007 14:03:03 -0600 Subject: [p2p-sip] Security update for charter In-Reply-To: <066d01c7392a$b09123a0$6701a8c0@china.huawei.com> References: <21520B56-B8AA-490F-B045-027E8DE07915@cisco.com> <066d01c7392a$b09123a0$6701a8c0@china.huawei.com> Message-ID: <45AD2F77.8020303@alcatel-lucent.com> Spencer Dawkins wrote: > I note that even the question of whether request bodies are > cryptotransparent to peers that handle requests is still an open > issue in the Concepts draft (section 4.5) We have done some work on this. We have implemented the idea of the sipsec URI to do end-to-end authentication and cryptotransparency across SIP proxies, especially in cases (NATs) where you need the proxies but do not trust them. The results indicate that: (a) it can be done (but we already knew that); (b) signaling latency is reduced by 1/2 when cryptotransparent proxies are used; (c) introducing a traditional TLS SIP proxy increases the latency by about 1/2 as much as it was before; introducing a cryptotransparent proxy has a much smaller impact on latency (10%). (d) System load as measured by CPU occupancy is negligible to the cryptotransparent proxies (CPU below 1% occupancy for the duration of processing 100 calls per second). We will be presenting these results as part of an upcoming paper. Thanks. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs From malexand at wu-wien.ac.at Tue Jan 16 15:56:42 2007 From: malexand at wu-wien.ac.at (Michael Alexander) Date: Tue, 16 Jan 2007 21:56:42 +0100 Subject: [p2p-sip] sip2p - an experimental p2psip app Message-ID: <45AD3C0A.9000003@wu-wien.ac.at> Dear all, we are happy to post sip2p, an experimental P2P SIP implementation. This is a small KadC/Kadmelia-based GPL application that allows to place calls between SIP clients. sip2p is written in C++ and should be fairly readable/extendable to new message types. Currently supported methods are REGISTER/INVITE. It has been tested with x-lite v2. A possible extensions would be support for SIMPLE/IM. The project is on sourceforge at - http://sourceforge.net/projects/sip2p Mailing list: sip2p-devel at lists.sourceforge.net Developers/contributors are cordially invited, Best Regards, Dr. Michael Alexander WU Wien Dept. of Information Systems malexand at wu-wien.ac.at / +43.1.31336.4467 GSM +43.699.1228.3586 From edpimentl at gmail.com Tue Jan 16 16:36:39 2007 From: edpimentl at gmail.com (EdPimentl) Date: Tue, 16 Jan 2007 16:36:39 -0500 Subject: [p2p-sip] sip2p - an experimental p2psip app In-Reply-To: <45AD3C0A.9000003@wu-wien.ac.at> References: <45AD3C0A.9000003@wu-wien.ac.at> Message-ID: <9dc4a1670701161336t7110518av97583df3ad3f34ac@mail.gmail.com> Hello Michael, We just launched a Sourceforge project to develop the base code per the IETF P2PSIP draft https://sourceforge.net/projects/viasip/ Would like to create a synergistic framework where together we can deliver on what members of the P2PSIP working group are hard at work defining. I can be reach at edpimentl[at]gmail{dot}com Sincerely and best regards, -E On 1/16/07, Michael Alexander wrote: > > Dear all, > > we are happy to post sip2p, an experimental P2P SIP implementation. > > This is a small KadC/Kadmelia-based GPL application that allows to place > calls between SIP clients. sip2p is written in C++ and should be fairly > readable/extendable to new message types. Currently supported methods > are REGISTER/INVITE. It has been tested with x-lite v2. A possible > extensions would be support for SIMPLE/IM. > > The project is on sourceforge at - > http://sourceforge.net/projects/sip2p > > Mailing list: > sip2p-devel at lists.sourceforge.net > > Developers/contributors are cordially invited, > > > Best Regards, > > Dr. Michael Alexander > WU Wien Dept. of Information Systems > malexand at wu-wien.ac.at / +43.1.31336.4467 GSM +43.699.1228.3586 > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -- -Ed Mail: edpimentl[at]gmail[dot]com Direct: 678.522.8511 VoIP: edpimentl [Skype | GoogleTalk] IM: edpimentl [ AOL | Jabber | Yahoo | MSN ] Mobile Content Management http://mobilecentral.ws Mobile Social Networks(Private Label) http://GooGaYa.com Mobile Payment http://AgilePAY.ws -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070116/8bbc460f/attachment-0001.html From jiang.x.f at huawei.com Wed Jan 17 03:34:29 2007 From: jiang.x.f at huawei.com (JiangXingFeng) Date: Wed, 17 Jan 2007 16:34:29 +0800 Subject: [p2p-sip] Comments to draft-baset-sipping-p2pcommon-00 In-Reply-To: Message-ID: <000001c73a12$4e553da0$7205a40a@china.huawei.com> Hi, Baset: I have read this draft. IMHO, when we design a protocol to be standardized, we not only standardize the message format of this protocol, but also define the message exchanges between two protocol entities and actions taken by the protocol entity when receive different protocol messages. Given Peer protocol, the message formats could be standardized like what you have proposed in the draft, but it is hard to standardize the message exchanges and actions required by protocol entities. For example, there is different process for Chord and Pastry. If a Node want to join a Chord overlay, then it send the join message to it's node key's successor and the successor would reply it with a response, which may include the route table of the successor and some pairs which should be responsible by the new Node. After doing that, the joining node would start fix finger and stabilization procedure to keep the route information correct. But in the case of Pastry, the joining node should get leaf set and neighbor set from other nodes than the node being responsible for the node ID in addition to obtain routing table from nodes which are encountered while the join request are routed through the overlay. So the join operation could trigger different message exchanges in each different DHT algorithm. How do you consider the heterogeneity of different DHT algorithms? If the heterogeneity could not be solved, I am afraid that a general Peer protocol accommodating various DHT algorithms may not be developed. It is good that you could add some content to make me convince that my worries are not necessary. Regards! -- Jiang XingFeng