Last Call Review of draft-ietf-ppsp-base-tracker-protocol-10
review-ietf-ppsp-base-tracker-protocol-10-genart-lc-gurbani-2015-10-15-00

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ppsp-base-tracker-protocol-10
Reviewer: Vijay K. Gurbani
Review Date: Oct-15-2015
IETF LC End Date: Not known
IESG Telechat date: Oct-15-2015

This document is ready as a Proposed Standard, however, it does have
some minor comments and nits that I detail below.

Major: 0
Minor: 3
Nits:  9

Minor:
- Generally speaking, I think one more round of edits for grammar and
  clarity may not be a bad thing.

- S2, "The PPSP Tracker Protocol architecture is intended to be
  compatible with the web infrastructure."  What is the "web
  infrastructure"?  How is it defined?  What does it mean to be
  compatible with it?  Perhaps you meant that the PPSP TP is a request-
  response protocol, which characterizes many "web protocols"?

- S3.2.5, Table 4: "available_bandwidth  | Upstream Bandwidth
  available" is this provisioned upload bandwidth or instantaneous
  upload bandwidth?

Nits:

- General comment: too much use of gratuitous capitalization (Request
  message, Tracker, Peer etc.)

- S1.1, CHUNK is better defined as "An uniformly sized atomic subset of
 the resource that constitutes the basic unit of data organized in P2P
 ..."

- S1.1, For uniformity when defining terms, you may want to think of
 starting the definition of live streaming as "LIVE STREAMING: Refers to
 ..."

- S1.1: The taxonomy of a peer into a leecher or a seeder appears to be
  absolute.  In real swarms (BitTorrent), a peer trades chunks with
  other peers, so it is a leecher but also a provider for certain
  chunks.  This eventuality is not considered here.

- S1.2.1, what is the implication of the prefix "[Peer Protocol]" in the
  numbered steps shown?  Is it a reference (using syntax like we use for
  references), or is it implying that the protocol used by a peer in
  these steps is the peer protocol?  If so, why not put the RFC/I-D
  number of the peer protocol there?

- S1.2.2, s/Once CONNECTed/Once connected/

- S2.2, what is an "action signal"?  Perhaps easier to simply say that
  "This Request message is used when ..."  Same with "information
  signal".

- S2.3.1, s/register on a tracker/register with a tracker/

- S3.1, "turning the definitions for JSON objects extensible."  I cannot
  quite parse that.  Sorry.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani at alcatel-lucent.com
Web: 

http://ect.bell-labs.com/who/vkg/

  | Calendar: 

http://goo.gl/x3Ogq