Dear all,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

*** Technical ***

Page 8:
> 
>    hash
>        The result of applying a cryptographic hash function, more
>        specifically a modification detection code (MDC) [HAC01], such as
>        SHA-1 [FIPS180-4], to a piece of data.

You probably want to mention SHA-256 rater than SHA-1, and essentially encourage the use of SHA-256 rather than SHA-1. Please see, e.g.:

* <

http://tools.ietf.org/html/rfc6194

>

*
<

http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2880823-recommendation-to-discontinue-use-of-sha-1.aspx

>

* <

https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

>

* <

https://www.schneier.com/blog/archives/2013/11/microsoft_retir.html

>


Section 8.13:

You should also include ULAs (which are essentially the equivalent f
RFC1918 address space), and probably mention that e.g. multicast addresses should be considered invalid irrespective of the source address.


Section 8.16:
> In the case of live streaming, where a push-model may be
>    used, the amount of data incoming is limited to the bitrate, which
>    the receiver must be able to process otherwise it cannot play the
>    stream.

This doesn't seem like a good justification for not having flow control.
Could you please elaborate on why flow control is not needed for this case?


Section 8.17, page 53:

The channel ID values employed might give the reader the impression that they are non-random. I'd suggest that, at the very least you note that these numbers were randomly selected, to avoid the case where an implementer assumes that they are selected from e.g. a global counter.



*** Nits ***

Section 2.2.:

>  If B or C decide to
>    choke A they sending a CHOKE message and A should then re-request
>    from other peers.

s/sending/send/


Section 3.10.1:

> They allow peers to exchange the
>    transport addresses of the peers they are currently interacting with,
>    thereby reducing the need to contact a central tracker (or DHT) to
>    discovery new peers.  

Please expand DHT.


Section 5:
> This scheme SHOULD be
>    used, for static content unless the protocol operates in a benign
>    environment.

Remove the comma.


Section 8.5:

>    (received and checked first four kilobytes of a file/stream)

This seems to be out of place...


Section 8.15:
>    A guideline for declaring a peer dead consist of a 3 minute delay
>    since that last packet has been received from that peer, and at least
>    3 datagrams were sent to that peer during the same period.

s/consist/consists/


Thank you,
Tina