Subject: [ppsp] Reviewing the tracker protocol

From: yunfei zhang <[email-masked]>
Date: Mon, 10 Jun 2013 17:50:28 +0800

Hi All,
   I have reviewed the tracker protocol draft and here is my comments:

*Overall:* I think this draft is on the right way of a RFC. Implementors
can write most of the codes on the communication bw peers and trackers
according to the draft. There are clear examples on the syntax and
semantics for reference.

*Comments:*
*1.Abstrct:* Since the main body doesn't invlove in different messages in
either adaptive multi-rate, layered (scalable) or multi-view (3D) videos
scenarios and this is mainly on different metadata out of scope of this
draft, it's better to remove the related description in the abstract (See
more in comment #16).
*2.Terminology:*
  a)Adaptive Streaming: "...for the same streaming session" is a little bit
confusing. Do you mean in a same viewing or just the same streaming content?
  b)Chunk: The definition in the Problem statement has been updated
according to the review.
  c)Definition related to presentation: Since the discussion of adaptive
multi-rate, layered (scalable)
   and multi-view (3D) videos scenarios is in the appendix, it seems better
to move them in the appendix.
  d) Media component: It seems not so clear on the definition.
  e)peer-ID: There is a missing ","after IP address.
  f) PPSP:The definition in the Problem statement has been updated
according to the review.
  g) Scalable Streaming: MVC is not explained clearly like SVC and MDC.
  h) Segment: Is it same as Chunk? Do we need the definition of Segement-ID?
  i) Tracker:The conception of "channel" is not explained.
*3.Enrollment and Bootstrap:*
   1)Since more roles like player and portal are introduced, it's better to
move the description on these roles,e.g., the relationship bw client media
player and the peer, currently in appendix, into this part.
   2) It's better to clarify that Portal+ MPD file is not the only means to
locate the tracker.
4.section 2.3, PPSP-TP should be present in the terminology.
5.Section 2.3.2, in the CONNECT part:
   a) When a peer registers in the tracker, it may not ask any swarm;
   b) Peer IP addresses is not sufficient to locate a peer;
   c) Doesn't the peer registers the Peer mode type informationl?
6. P13, Para2,"each Peer-ID is modeled" or "each peer is modeled"?
7.Section 2.4.1,4)When Tracking, is there a need to send again a "CONNECT"?
8. How to convey the SM state information to the tracker?
9.Section 3.1, transaction-ID is not explained in terminology part.
10. Table 2, it's suggested to add the attribute "battery power"for mobile
peers.
11.Section 4.1, it's better to limit the maximum number of the peers in the
peerlist to avoild DoS attack or maliciously getting the whole picture of
the active peers in short time for profit.
12. P29,Are PEER REGISTERED and TRACKING states in the tracker or peers?
13. Section 6.4, it's not clear about pro-incentive parameter.Needs more
descrption.
14.In the security part, the maclious action of asking peer-list with large
amount of peers should be noted.
15.Appedix B1, the Authorization header field is not present in the
example. And this mechanism should be highlighted.
16. It's better to have sperate drafts to discuss Appedix C.
17. Does OAth 2.0 well suit the authentication bw tracker and peers? I
understand that oAuth is best suited in 3rd-party application
authorization,not authentication. Am I right?

BR
Yunfei