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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 15 Oct 2015 13:35:55 -0500

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 22 Oct 2015 07:46:11 +0000

Hi Vijay,

Thank you for the review. Please see our replies inline starting with [Rachel]. 

BR,
Rachel

> 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:

[Rachel]: Will do.

>    response protocol, which characterizes many "web protocols"?

[Rachel]: Right. Will fix it.

>    available" is this provisioned upload bandwidth or instantaneous

[Rachel]: It's available instantaneous upload bandwidth. Will add some clarifications.

>    message, Tracker, Peer etc.)

[Rachel]: Will fix it in the next version.

>   the resource that constitutes the basic unit of data organized in P2P

[Rachel]: As for the terminologies. I think it's better to reference RFC6972. So maybe just delete those already defined in [RFC6972] and keep those new ones.

>   starting the definition of live streaming as "LIVE STREAMING: Refers to

[Rachel]: Ok.

>    number of the peer protocol there?

[Rachel]: Sorry, it should be [RFC7574].

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

[Rachel]: Accepted. Will fix them in the next version.

> - S3.1, "turning the definitions for JSON objects extensible."  I cannot

[Rachel]: This sentence should be deleted.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 22 Oct 2015 15:04:26 -0500

Rachel: Thank you for attending to all my comments.

>    chunks.  This eventuality is not considered here.

Any thoughts on how to proceed?

Other than that, I am fine with the resolution to the remaining ones.

Thanks,

- vijay

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 23 Oct 2015 01:27:19 +0000

Hi Vijay,

Sorry for omitting this one.

It is absolute:
A leecher is a peer that is downloading chunks from other peers, but it does not have the complete content. And of course, it is uploading while downloading. 
A seeder has complete copies of the content. So it is only uploading.
A leecher can become a seeder once it finishes downloading. But a peer can't be both a leecher and seeder at the same time.

BR,
Rachel

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Friday, October 23, 2015 4:04 AM
> To: Huangyihong (Rachel); [email-masked]
> Cc: General Area Review Team;
> [email-masked];
> [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10
>