Re: [ppsp] Request: draft-cruz-ppsp-base-tracker-protocol as WG item

[Arno Bakker <[e-mail]>]

Hi Rui et al.

please see inline:

On 13/11/2012 13:18, Rui Cruz wrote:
>
>> p. 13. Why doesn't a peer in SEED mode connect to other peers?
>> Especially in a world with NAT boxes it may be necessary for seeders
>> to initiate the connection themselves.
> Nothing prevents a peer with all content (seed) to connect to other
> peers. But that is an implementation of the Peer, and the Peer Protocol,
> not of the Tracker, or the Tracker Protocol.
>

At the moment when peerMode is SEED the tracker appears not to send a 
peer list (p. 27 at bottom). Please clarify how a seed obtains a peer 
list, e.g. does PeerNum take priority over peerMode?


> The STAT_REPORT has two purposes: 1) a status heart-beat (mandatory) for
> the tracker to keep the peer Registered (facilitating cleaning up of
> inactive/vanished peers in the swarm); 2) reporting statistic data
> (optional)
>

For function 1, CONNECT suffices, see p. 17 2nd item. This means that
STAT_REPORT can be made truly optional. At the moment STAT_REPORT is 
mandatory ("This request message MUST be sent periodically to the 
tracker", p. 14.)


>> My major concern is security, in particular, when the tracker supports
>> returning peers based on criteria specified by the client.
> .....
>> For a tracker to be able to reply to such queries it must receive this
>> information somehow.
> That information can be received by the Tracker in STAT_REPORTs.
>
>> The draft suggests a global trust mechanism, but that is currently not
>> available. I therefore propose to remove this capability-based peer
>> selection until that time. Instead, the tracker should always return a
>> random sample from the peer population.
> This is an implementation issue of the Tracker service.
> The tracker protocol itself supports the transfer of the associated
> information, if desired. The most basic information is just the number
> of peers to be returned in a list, without reference to any "special"
> capabilities. The PeerNUM element and attributes are not even mandatory.
>

But if it is currently not possible to implement a tracker service that 
offers this functionality and is secure in a malicious environment, the 
support for it should not be in the tracker protocol, IMHO.

CU,
     Arno

P.S. Typo: There are also references to a Section 8.6 in the draft, 
which no longer exist.