Original text:
This is a request for the entire body. This is used to confirm that the current set of MAX_PAYLOADS <del> payloads have been successfully received and that, upon receipt, the peer can continue to sent the next set of payloads.  This is the 'Continue' Q-Block-2. </del>  <del> This is a request for the remaining payloads in the current MAX_PAYLOADS set. </del>  If the request includes multiple Q-Block2 Options and these options overlap (e.g., combination of M being set (this and later blocks) and these missing blocks is as follows: The token to use for the response SHOULD be the token that was used <del> in the highest block number received payload.  Note that the use of any received token would work, but providing the one used in the highest received block number will aid any troubleshooting.  The client will use the token to match the request to find what Request- Tag value is currently being used. </del>  If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined by Section 4.6 RFC7252, then the number

Reviewer comments:
The draft describes this all as "just working through a proxy" -- original block-wise does not, and I'd like to hear how this is hoping to get away without the options being proxy-unsafe. Is there any point at all in using block-by-block proxying for these use cases? Unless a proxy is sitting right inside the link under attack, and unless the bodies get huge, it may be way easier for this to be purely hop-by-hop. Proxies would reassemble the full bodies and, for the next hop, just decide what works best there (be it regular block-wise, Block34 or BERT). (If there's a point in allowing block-by-block forwarding, we can talk it through and work through the initial ideas that will come up like "We use large enough Request-Tag values so they are unique", "how large does that need to be", "why do we end up having a Request-Tag in every request now" and "why do we not want that", but my gut feeling is we won't need to go there.)

Revised text:
This is a request for the entire body. This is used to confirm that the current set of MAX_PAYLOADS  <ins> payloads (the latest one having block number NUM-1) has been successfully received and that, upon receipt of this request, the server can continue to send the next set of payloads (the first one having block number NUM).  This is the 'Continue' Q-Block-2. </ins>  <ins> This is a request for that block and for all of the remaining blocks in the current MAX_PAYLOADS set. </ins> If the request includes multiple Q-Block2 Options and these options overlap (e.g., combination of M being set (this and later blocks) and these missing blocks is as follows: The token to use for the response SHOULD be the token that was used  <ins> in the highest block number received so far with the same Request-Tag value.  Note that the use of any received token with the same Request-Tag would work, but providing the one used in the highest received block number will aid any troubleshooting.  The client will use the token to determine what is the previously sent request to obtain the Request-Tag value to be used. </ins> If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined by Section 4.6 RFC7252, then the number