[ppsp] Tracker draft review

[Arno Bakker <[e-mail]>]

Hi all

here is my review of the draft-gu-ppsp-tracker-protocol-07 proposal:

p.5. Would the proposed usage guide not be a better place for
the 1.1 + 1.2 tutorials?

p.8. IMHO the draft should list the requirements for the enrollment 
certificates.

p.8. Typo: "encoded alternative" -> "encoded alternatives"

p.10. Peer-Peer messages. Please add a reference to the peer protocol WG 
item.

p.12. "Each peer ... contacts the tracker to advertise which information
it has available". This is not required for all trackers, just the ones
that use this info to steer peer selection. See PPSP.TP.REQ-7.

p.13. Typo: "5. Peer requests for" -> "5. Peer requests"

p.14. Typo: "registers in the tracker" -> "registers with the tracker"

p.15. Concept PeerMode type is used without introduction.

p.15. Typo: "to request to the tracker" -> "to request from the tracker"

p.15. IMHO one can remove the TERMINATED state.

p.16. State machine: Does a peer need to be connected to a tracker all 
the time?

p.20 "Content-Lenght" -> "Content-Length"

p.23. What is the value of "Content-Type" for the tracker protocol?

p.23. Concept PeerGroup is used without introduction.

p.24. Elements like PeerMode, PeerGroup will not be used by all tracker 
implementations, so should be marked "MAY".

p.25. What are the security implications of the PeerMode, 
uploadBWlevel, onlineTime elements? What if malicious peers claims to 
e.g. have high bandwidth, can they gain an advantage here that would 
allow them to eclipse or disrupt the service?

p.26. What are the security implications of having a peer announce its
own IP address, connection, ASN, etc. instead of the tracker gathering
this information independently from the network?

p.28. What are the security implications of a peer sending information 
about its available bandwidth?

p.30. CONNECT: Please specify which fields are mandatory and which 
optional. E.g. link status.

p.32. No PeerID in CONNECT response?

p.34. Typo: "SUCCESSFULL" -> "SUCCESFUL"

p.35. 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.

p.39. Typo: "START_REPORT" -> "STAT_REPORT"

p.40. "If the length of the message does not matches the Content-Length"
How will you know, given HTTP is run over TCP which is a byte stream?

p.42. Peers may also refuse to servce content and put QoS at risk.

p.42. Will the tracker protocol function today, without this global 
trust mechanism?

p.46. Appendix B. Where do the MPDs play a role in the tracker protocol?
The proposed usage guide may be a better place, and a reference to the 
ISO/IEC 23009-1 would suffice IMHO.

p.50. - PPSP-REQ-6: What is the chunk addressing scheme used? Should 
support multiple.

p.50. - PPSP.TP.REQ-7: ChunkMaps are optional.
p.51. - PPSP.TP.REQ-8: BASE64-encoding is not compact, actually it takes 
more bytes than original data. I.e. no compression here.

p.51. - PPSP.SEC.REQ-1: How does the tracker protocol support closed 
swarms? What's its role?

p.51. - PPSP.SEC.REQ-2: What role does tracker play in content 
confidentiality?

p.51. - PPSP.SEC.REQ-7: How does the design support distributed 
architectures like DHTs and gossip?

p.52. - PPSP.SEC.REQ-9: Using MPDs for content integrity protection is 
only one particular scheme. Please allow for multiple.

Regards,
     Arno