Subject: [ppsp] next step of tracker document

From: Xiajinwei <[email-masked]>
Date: Mon, 10 Sep 2012 07:51:51 +0000

Hi all,

I notice there are two concerns in tracker document from IETF 84 meeting minutes, in order to accelerate the processing of this document, I'd like to show my understanding firstly. Hope we can push this work forward and get consensus as soon as possible.

1, Peer ID is global unique to identify the Peer, from this point of view, the Peer IP address is optional to identify the Peer. IMO it could be useful in a closed swarm scenario, in which the peers (both leech and seed) are behind the NAT and they can share the media content in the local domain (e.g., enterprise inside). If I am right, I suggest some text should be given to describe this scenario.

2, Encoding xml or binary experiences a long discussion, different person have different preference. One compromise is encoding and decoding XML in binary, the related context is specified in W3C Efficient XML Interchange Working Group or in ISO/IEC 23001-Part 1 "Binary MPEG format for XML". Therefore, encoding both XML and HTTP in binary format are implementation options. The draft can have a couple of paragraphs providing those options in terms of implementation notes.

Any comments?

Thank you!

Jinwei

---

From: zhangyunfei <[email-masked]>
Date: Mon, 10 Sep 2012 16:15:47 +0800

Hi Jinwei,
    For point1, when you mention peer IP address is optional to identify the peer. Do you mean it's *feasible* or a *suitable candidate*? If it were the case, I agree with you at this point.
   For  point2, the consensus in last IETF on this draft should be "concentrating on the message* if I don't remember wrong. Regarding the encoding part, you can ask Wes and Fabio for more comments.

Thanks.
BR
Yunfei 

zhangyunfei

From: Xiajinwei
Date: 2012-09-10 15:51
To: [email-masked]
Subject: [ppsp] next step of tracker document
Hi all,
 
I notice there are two concerns in tracker document from IETF 84 meeting minutes, in order to accelerate the processing of this document, I’d like to show my understanding firstly. Hope we can push this work forward and get consensus as soon as possible.

2, Encoding xml or binary experiences a long discussion, different person have different preference. One compromise is encoding and decoding XML in binary, the related context is specified in W3C Efficient XML Interchange Working Group or in ISO/IEC 23001-Part 1 ”Binary MPEG format for XML”. Therefore, encoding both XML and HTTP in binary format are implementation options. The draft can have a couple of paragraphs providing those options in terms of implementation notes.
 
Any comments?
 
Thank you!

Jinwei

---

From: Xiajinwei <[email-masked]>
Date: Mon, 10 Sep 2012 08:36:40 +0000

Hi Yunfei,

Wow, your feedback is very prompt!

Yes, the Peer IP information can be used in a limited scenario, for example, all the peers are in a enterprise network and are behind the enterprise NAT, they can transmit the enterprise files among the enterprise network via their local IP addresses. But the Peer ID is mandatory and can’t be replaced by Peer IP information IMHO.

Do you mean the conclusion is removing encoding type related text from this document? if yes, will the text be moved into another document, e.g., tracker extension draft?

Thank you!

Jinwei

发件人: zhangyunfei [mailto:[email-masked]]
发送时间: 2012年9月10日 16:16
收件人: Xiajinwei; ppsp
主题: Re: [ppsp] next step of tracker document

Hi Jinwei,

Thanks.
BR
Yunfei
________________________________
zhangyunfei

From: Xiajinwei<mailto:[email-masked]>
Date: 2012-09-10 15:51
To: [email-masked]<mailto:[email-masked]>
Subject: [ppsp] next step of tracker document
Hi all,

Any comments?

Thank you!

Jinwei

---

From: zhangyunfei <[email-masked]>
Date: Mon, 10 Sep 2012 18:12:58 +0800

Hi Jinwei (Speaking individually),
     My suggestion is to consider peer IP(private, public)+port(private, public) for the purpose of identifying the peer. Is it enough? Or we may need more information for the identification.
     I am not meaning totally removing the encoding in the tracker protocol. However I suggest in current stage, encoding part may be placed in the appendix part, as a step to realize the consensus in last IETF. 
    Regarding the encoding proposal you raised, my feeling is that we at least need to ask the people with concerns in last IETF (See the minutes) for their comments.

BR
Yunfei

zhangyunfei

发件人： Xiajinwei
发送时间： 2012-09-10 16:36
收件人： zhangyunfei; ppsp
主题： 答复: [ppsp] next step of tracker document
Hi Yunfei,

 
 
Thank you!

Jinwei

Hi Jinwei,
 
Thanks.
BR
Yunfei 

zhangyunfei
 
From: Xiajinwei
Date: 2012-09-10 15:51
To: [email-masked]

 
 
Any comments?
 
Thank you!

Jinwei

---

From: stefano previdi <[email-masked]>
Date: Mon, 10 Sep 2012 17:58:53 +0200

Jinwei,

>      My suggestion is to consider peer IP(private, public)+port(private, public) for the purpose of identifying the peer. Is it enough? Or we may need more information for the identification.

I tent to agree.

We need a mechanism that will work the _same_ for any kind of deployment (private/public).

s.

> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: Xiajinwei <[email-masked]>
Date: Tue, 11 Sep 2012 02:07:24 +0000

Hi Stefano and Yunfei,

If we consider a general mechanism to identify Peer, "IP+Port" will be a good candidate, which can apply to either global or local scenario. Cruz, if you agree this, we can rephrase our document.

I agree to your suggestion, we can remove encoding parts into appendix temporarily, adopt tracker protocol and work on message parts at first, and then decide the encoding type later. This processing looks good for me. 

Any other comments? Cruz?

BR
Jinwei

> -----邮件原件-----
> 发件人: stefano previdi [mailto:[email-masked]]
> 发送时间: 2012年9月10日 23:59
> 收件人: zhangyunfei
> 抄送: Xiajinwei; ppsp
> 主题: Re: [ppsp] 回复: 答复: next step of tracker document
> 
> Jinwei,
> 
> >      My suggestion is to consider peer IP(private, public)+port(private,
> public) for the purpose of identifying the peer. Is it enough? Or we may need
> more information for the identification.
> 
> 
> I tent to agree.
> 
> >      I am not meaning totally removing the encoding in the tracker protocol.
> However I suggest in current stage, encoding part may be placed in the
> appendix part, as a step to realize the consensus in last IETF.
> >     Regarding the encoding proposal you raised, my feeling is that we at
> least need to ask the people with concerns in last IETF (See the minutes) for
> their comments.
> >
> > BR
> > Yunfei
> >
> >
> >
> > zhangyunfei
> >
> > 发件人： Xiajinwei
> > 发送时间： 2012-09-10 16:36
> > 收件人： zhangyunfei; ppsp
> > Yes, the Peer IP information can be used in a limited scenario, for example, all
> the peers are in a enterprise network and are behind the enterprise NAT, they
> can transmit the enterprise files among the enterprise network via their local
> IP addresses. But the Peer ID is mandatory and can’t be replaced by Peer IP
> information IMHO.
> >
> > Do you mean the conclusion is removing encoding type related text from this
> document? if yes, will the text be moved into another document, e.g., tracker
> extension draft?
> >
> > Thank you!
> >
> >
> > Jinwei
> >
> >     For point1, when you mention peer IP address is optional to identify the
> peer. Do you mean it's *feasible* or a *suitable candidate*? If it were the case,
> I agree with you at this point.
> >    For  point2, the consensus in last IETF on this draft should be
> "concentrating on the message* if I don't remember wrong. Regarding the
> encoding part, you can ask Wes and Fabio for more comments.
> >
> > Thanks.
> > BR
> > Yunfei
> > zhangyunfei
> >
> > From: Xiajinwei
> > Date: 2012-09-10 15:51
> > To: [email-masked]
> > I notice there are two concerns in tracker document from IETF 84 meeting
> minutes, in order to accelerate the processing of this document, I’d like to
> show my understanding firstly. Hope we can push this work forward and get
> consensus as soon as possible.
> >
> > 1, Peer ID is global unique to identify the Peer, from this point of view, the
> Peer IP address is optional to identify the Peer. IMO it could be useful in a
> closed swarm scenario, in which the peers (both leech and seed) are behind the
> NAT and they can share the media content in the local domain (e.g., enterprise
> inside). If I am right, I suggest some text should be given to describe this
> scenario.
> >
> > 2, Encoding xml or binary experiences a long discussion, different person have
> different preference. One compromise is encoding and decoding XML in binary,
> the related context is specified in W3C Efficient XML Interchange Working
> Group or in ISO/IEC 23001-Part 1 ”Binary MPEG format for XML”. Therefore,
> encoding both XML and HTTP in binary format are implementation options. The
> draft can have a couple of paragraphs providing those options in terms of
> implementation notes.
> >
> > Any comments?
> >
> > Thank you!
> >
> >
> > Jinwei

---

From: Zongning <[email-masked]>
Date: Mon, 17 Sep 2012 01:27:38 +0000

For point two, I agree that we can move the encoding part of tracker protocol to appendix, as both XML and binary are at least feasible.
But I would *strongly* want to hear the comments from the people raising this issue in last PPSP session about encoding – for example, efficiency concerns?
Thanks.

-Ning

From: [email-masked] [mailto:[email-masked]] On Behalf Of zhangyunfei
Sent: Monday, September 10, 2012 6:13 PM
To: Xiajinwei; ppsp
Subject: [ppsp] 回复: 答复: next step of tracker document

BR
Yunfei

发件人： Xiajinwei<mailto:[email-masked]>
发送时间： 2012-09-10 16:36
收件人： zhangyunfei<mailto:[email-masked]>; ppsp<mailto:[email-masked]>
主题： 答复: [ppsp] next step of tracker document
Hi Yunfei,

Thank you!

Jinwei

Hi Jinwei,

Thanks.
BR
Yunfei

Any comments?

Thank you!

Jinwei