Subject: [Gen-art] Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10
From: "Vijay K. Gurbani" <[email-masked]>
To: [email-masked]
Cc: General Area Review Team <[email-masked]>, [email-masked], [email-masked]
Date: Thu, 15 Oct 2015 13:35:55 -0500
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>

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} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq