This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Thank you for preparing such a clearly written, precise, specification. On 
the whole, this is very good. I just have some minor issues to consider.

Section 4.1 says “To indicate support for Q-Block2 responses, the CoAP 
client MUST include the Q-Block2 Option in a GET or similar request 
(FETCH, for example), the Q-Block2 Option in a PUT or similar request, or 
the Q-Block1 Option in a PUT or similar request so that the server knows 
that the client supports this Q-Block functionality” – It would be useful to
enumerate what are “similar” requests.

Section 5: “Such messages must not be treated by the client as a fatal error“ 
- I was surprised this is not a normative MUST NOT.

Section 7.1: “For faster transmission rates, NSTART will need to be increased 
from 1.  However, the other CON congestion control parameters will need to 
be tuned to cover this change.  This tuning is out of scope of this document as 
it is expected that all requests and responses using Q-Block1 and Q-Block2 will 
be Non-confirmable (Section 3.2).” - The way this is phrased is difficult to parse. 
I can interpret it as saying that the transmission rate *does* need to be faster, so 
implementations need to increase NSTART and tune the other parameters. 
Alternatively, I can interpret this as saying that *if* the transmission needs to
be faster, then NSTART and the other parameters need to be tuned in some
as-yet-unspecified way. The text would benefit from being rephrased to clarify
which meaning is intended. 

What happens when NSTART is increased beyond 1, and how the other parameters
are tuned, is unclear. The text would be better if it either cross-referenced to the
definition of how the parameters are to be tuned, or explicitly stated that this is not
yet supported and will need to be defined in some future extension.

In Section 7.2, I’m not convinced by the argument to set MAX_PAYLOAD to 10 for
similar reasons to RFC 6928. The types of link layer that CoAP runs over are very 
different to those measured to support the increase in TCP’s initial window. An
argument based on typical properties of links and buffer space in networks used by
CoAP would be more convincing (I accept that using MAX_PAYLOAD of 10 is not
going to do any significant harm, even if it is higher than optimal).

Section 7.2 also notes that “PROBING_RATE and other transmission parameters are
negotiated between peers”. It would be appropriate to give some guidance on what
are the bounds for safe values that can be negotiated for these parameters.

Section 7.2 says:

>   As the sending of many payloads of a single body may itself cause
>   congestion, it is RECOMMENDED that after transmission of every set of
>   MAX_PAYLOADS payloads of a single body, a delay is introduced of
>   NON_TIMEOUT before sending the next set of payloads to manage
>   potential congestion issues.

and the following paragraph has guidance for reducing MAX_PAYLOADS if
persistent congestion occurs “for at least a 24 hour period and it is known
that there are no other network issues over that period”. It’s not clear how
an implementation will know about other network issues, and I would suggest
that even if there are such issues, backoff would be appropriate given persistent
congestion. 

Finally, is there are mechanism for gradually recovering MAX_PAYLOADS to 
its original value, if persistent loss ceases for some period?