Hi Vijay,
Thank you for the review. Please see our replies inline starting with [Rachel].
BR,
Rachel
>
> 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.
[Rachel]: Will do.
>
> - 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"?
[Rachel]: Right. Will fix it.
>
> - S3.2.5, Table 4: "available_bandwidth | Upstream Bandwidth
> available" is this provisioned upload bandwidth or instantaneous
> upload bandwidth?
[Rachel]: It's available instantaneous upload bandwidth. Will add some
clarifications.
>
> Nits:
>
> - General comment: too much use of gratuitous capitalization (Request
> message, Tracker, Peer etc.)
[Rachel]: Will fix it in the next version.
>
> - 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
> ..."
[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.
>
> - S1.1, For uniformity when defining terms, you may want to think of
> starting the definition of live streaming as "LIVE STREAMING: Refers to
> ..."
[Rachel]: Ok.
>
> - 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?
[Rachel]: Sorry, it should be [RFC7574].
>
> - 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/
[Rachel]: Accepted. Will fix them in the next version.
>
> - S3.1, "turning the definitions for JSON objects extensible." I cannot
> quite parse that. Sorry.
[Rachel]: This sentence should be deleted.
>
> 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 protected]
> Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
