Re: [ppsp] tickets for IETF 83

[stefano previdi <[e-mail]>]

On May 16, 2012, at 3:40 AM, zhangyunfei wrote:

> Thanks Rui for the clarification. I would suggest to sperate the base specification and the extensions with two different drafts for two reasons:
> 1) It would be much easier to get consensus on the base draft since its scope is highly limited. In this way the progress will be earlier to achieve.
> 2) We see many similar operations in IETF drafts practices which may be proved to be an efficient way in IETF circle.


yes, different drafts is the best choice so we can move them on 
autonomously from each other. The goal, at this stage, is to reach 
consensus on the base specification in a reasonable time.

Extensions will go in separate documentS (i.e.: we may need more 
than one extension document).

It's a common IETF practice with proven efficiency.

s.


>  
> BR
> Yunfei 
>  
> zhangyunfei
>  
> From: Rui Cruz
> Date: 2012-05-15 18:59
> To: ppsp
> CC: Rui Cruz; Picconi Fabio; Yingjie Gu(yingjie); zhangyunfei ([e-mail])
> Subject: Re: [ppsp] tickets for IETF 83
> Hi,
> 
> On Ticket #4: The FIND use case can perfectly be seen as Fabio described, i.e., "to find peers subject to attribute constraints" in order to speed up discovery, i.e., may be used in special situations only, therefore, the overhead to the tracker can be considered minimal.
> 
> On Ticket #5: The tracker protocol proposal is being split in a base specification and extensions. We do not see the need for "additional messages e.g.,reconnect and rejoin)" as this type of "action" is perfectly solved with the already proposed messages.  This is the case of the new semantic for the CONNECT message with implicit JOINs which behaves as a re-CONNECT with re-JOINs.
> 
> We would appreciate an advise from the chairs on splitting the tracker protocol proposal in a base specification and extensions. Should it be done with two different draft documents or with a single document where the extensions are clearly separate to an Annex??
> 
> Regards,
> 
> Rui Cruz
> [e-mail]
> 
> IST/INESC-ID/INOV - Lisbon, Portugal
> __________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp
> 
> On 15/05/2012, at 04:10, zhangyunfei wrote:
> 
>> Hi Rui and Yingjie,
>>     Would you please confirm the ticket #4 for Paris meeting?
>>      For ticket #5, I am fine with Fabio's proposal.
>>  
>> BR
>> Yunfei
>>  
>> zhangyunfei
>>  
>> From: Picconi Fabio
>> Date: 2012-05-14 20:04
>> To: zhangyunfei; ppsp
>> Subject: RE: [ppsp] tickets for IETF 83
>> Hi,
>> Somme comments:
>> Ticket #1 (chunk addressing mechanism). See my email send today.
>> Ticket #2. I can’t remember what this was about. :-)
>> Ticket #3 (secure PEX): I think that we can stick to a simple PEX mechanism that can be augmented by an optional secure algorithm. In addition to the solution proposed by Arno, there is a simple mechanism described by Jesi et al. [1].
>> Ticket #4 (FIND use case). I don’t recall exactly the details of this issue. If it’s only motivating a request to the tracker to find peers subject to attribute constraints, then finding peers with a similar upload capacity (to speed up the discovery phase) is already a good motivation.
>> Ticket #5 (additional messages). I think the proponents of these messages should describe the use cases where these messages can be useful.
>> Cheers,
>> Fabio
>> [1] G.P. Jesi, A. Montresor, and M. van Steen. Secure Peer Sampling. In Computer Networks, 2010.
>>  
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of zhangyunfei
>> Sent: jeudi 3 mai 2012 10:13
>> To: ppsp
>> Subject: [ppsp] tickets for IETF 83
>>  
>> Hi all,
>>     I have summarized an initial tickets list for IETF 83 meeting. Please review it and actions on these tickets are expected. Thanks.
>>  
>> BR
>> Yunfei &Stefano
>> -----------------------------------------------------------------------------------------------------------
>> Peer protocol:
>> Ticket #1：Post and discuss the alternative proposal besides MHT in peer protocol (Proposal 10+13), list intervals (Tradeoff among complexity / overhead / efficiency / implementation) and check gaps. [Martin，Yunfei, Fabio, Lichun]
>> This ticket is partly solved. Simple nature number addressing and ranged expression on chunk availability. The analysis and comparison is ongoing. I'd suggest to have a deadline for the resolution time after discussing with Stefano, i.e.,  May 26th from now on to make the decision in the WG level.
>>  
>> Ticket #2：Discuss the possible “"state-building attacks" attack on peers.[Martin](related Proposal 26)
>> Martin, Do you still have concerns on this? If nobody shows up, we propose to close this ticket.
>>  
>> Ticket #3: Discuss the Membership certificates impact on the tracker’s workload.[Fabio](related to Proposal 17+20)
>>  
>> Tracker protocol:
>> Ticket#4: Specify the FIND use case and reduce the overhead to the tracker.[Martin,Yunfei，Fabio，Richardo]
>> Ticket#5: Discuss concrete use cases of additional messages if there are(e.g.,reconnect and rejoin) , and conclude the basic messages and optional ones in tracker protocol. [Mark, Fabio]
>>  We propose to the tracker protocol authors to address their tickets with a splitting of their proposal:
>> . base spec
>> . additional options.
>>  
>> Survey
>> Ticket#6: Call for reviewers for survey draft, and maybe P2P streaming providers’ contribution on updating the draft.   
>>  
>> zhangyunfei
>> _______________________________________________
>> ppsp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ppsp
> 
>