Re: [ppsp] comments for gu-ppsp-tracker-protocol and gu-ppsp-peer-protocol

"Yingjie Gu(yingjie)" <guyingjie@huawei.com> Tue, 05 July 2011 08:03 UTC

Date: Tue, 05 Jul 2011 16:03:24 +0800
From: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
In-reply-to: <OFE0FDEB39.F7D132EB-ON482578BF.0034E276-482578C3.00221512@zte.com.cn>
To: li.lichun1@zte.com.cn, ppsp@ietf.org
Message-id: <003701cc3aea$03dec0b0$0b9c4210$@com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_Fdl3JsR40DSPpi1koIbGPQ)"
Content-language: zh-cn
Thread-index: Acw6EbOpQ2XUnAbOTW+vFQEdSVR7CwA1gBxQ
References: <OFE0FDEB39.F7D132EB-ON482578BF.0034E276-482578C3.00221512@zte.com.cn>
Subject: Re: [ppsp] comments for gu-ppsp-tracker-protocol and gu-ppsp-peer-protocol
Precedence: list

Hi Lichun,

Thank you very much for your comments. 

See inline please.

 

  _____  

Best Regards
Gu Yingjie

 

发件人: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] 代表
li.lichun1@zte.com.cn
发送时间: 2011年7月4日 乐乐14:12
收件人: ppsp@ietf.org
主题: [ppsp] comments for gu-ppsp-tracker-protocol and gu-ppsp-peer-protocol

 


Comments for draft-gu-ppsp-tracker-protocol-04. 
1. 
Section 6 
 "To protect signaling from impersonation attackers, who pretend to be 
   another peer rather than their authentic identities, certificates 
   along with TLS/DTLS could be used to ensure that each message is sent 
   from an authorized participant (tracker or peer) of the P2P streaming 
   system." 

HTTP is based on TCP. I think only TLS is applicable. 



[Gu] Yes, Thank you.



2. 
The example of peer list is not given. 

[Gu] I will add an example in next version.


Comments for draft-gu-ppsp-peer-protocol-02. 

1. 
Is it better to add <DestPeerID> in messages? 

[Gu] You are right. 


2. 
"3.1.  Protocol Architecture 

   The proposed PPSP Peer Protocol uses a newly defined, light weight 
   gossip protocol between the peers to exchange the actual information, 
   but uses the RELOAD [I-D.ietf-p2psip-base] protocol to establish the 
   connections between peers and to locate other peers with which to 
   establish gossip protocol connections." 

Tracker protocol draft and peer protocol draft should consider
not-implementing-NAT-traversal instead of RELOAD as default. 
Implementing and using RELOAD is not neccesary if there is no NAT or the
ratio of NATed peer is very low. 
RELOAD is not the only way to establish connection to NATed peers. Otherthan
RELOAD, there is another way (PPSP-ICE), which is proposed in my NAT
traversal draft. 
Using RELOAD or PPSP-ICE brings more work to implementing a P2P streaming
system. 
[Gu] Yes you are right, I should revise this sentence. I remember that in
this version of the Tracker protocol, I have removed the default reference
to RELOAD for NAT traversal. And I do assume that no NAT is involved, and
pointed out in the text that there are other drafts describe how to resolve
NAT traversal. The Tracker and peer protocol won’t take NAT Traversal into
account but will be ready to update based NAT traversal requirements that
are raised by other drafts and are regarded as necessary by the WG. I will
revise this sentence. Thank you for your review. 

BR 
Lichun

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

[ppsp] comments for gu-ppsp-tracker-protocol and … li.lichun1
Re: [ppsp] comments for gu-ppsp-tracker-protocol … Yingjie Gu(yingjie)