[Gen-art] Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10

"Vijay K. Gurbani" <vkg@bell-labs.com> Thu, 15 October 2015 18:36 UTC

Return-Path: <vkg@bell-labs.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64361AD0CD; Thu, 15 Oct 2015 11:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxJGcGj7mOXP; Thu, 15 Oct 2015 11:36:07 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360AC1B3440; Thu, 15 Oct 2015 11:36:01 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id AEF9B54D972CD; Thu, 15 Oct 2015 18:35:54 +0000 (GMT)
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t9FIZuWM005545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Oct 2015 18:35:56 GMT
Received: from [135.185.238.169] (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id t9FIZu2T002817; Thu, 15 Oct 2015 13:35:56 -0500 (CDT)
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
To: draft-ietf-ppsp-base-tracker-protocol@tools.ietf.org
Message-ID: <561FF20B.1030302@bell-labs.com>
Date: Thu, 15 Oct 2015 13:35:55 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/B2IQvvS8Wk7ZZ62oB8UrEoG1fwM>
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-ppsp-base-tracker-protocol.chairs@ietf.org, draft-ietf-ppsp-base-tracker-protocol.ad@ietf.org
Subject: [Gen-art] Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 18:36:09 -0000

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@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq