Block-Wise Transfers in the Constrained Application Protocol (CoAP)
draft-ietf-core-block-21

I moved the following from a DISCUSS to a COMMENT, pending the next revision:

-- START:
This should be easy to clean up, and it's entirely possible I am misreading something. But Section 3.4, 2nd and 3rd paragraph seem to be inconsistent in SHOULD vs MUST for block size.  I _think_ I'm reading the following:

1. If the client requests a specific block size, the server MUST use that size or a smaller one. 

2. Any subsequent requests from the client MUST indicate the same size that the server used

3. But paragraph 3 then says all further requests SHOULD indicate the same size. But if they already MUST indicate the same size as in the initial response, then this   SHOULD seems non-constraining at best, and at worst in conflict with 1. (ignoring the last-block size issue for the moment.)

4. Then paragraph 3 goes on to say the server SHOULD use the block size indicated in the request or smaller. This seems to conflict with the MUST in 1.

5.  Then it again asserts that the client MUST indicate the same size in subsequent requests, conflicting with the SHOULD in 3., but agreeing with the MUST in 1.

-- END


Substantive:

- General: The draft dives into detail without giving much context until the examples. The reader is left to infer the forest from the trees. It would be very helpful (to me, at least) to add a high-level overview of operation early in the document, including definitions for "descriptive" vs " control" usages. (I know it's late in the process to ask for a whole new section, so I won't push the point.)

- The distinction between the option names Block1 and Block2 seems almost actively non-mnemonic. Is that intentional? (I won't push this point, either.)

- 3.4: Does the eTag apply to the "payload" or the whole "body"?

- 2.5, 2nd paragraph, last sentence:
Should I read this to mean that the reduction in block size is retroactive? That could use some elaboration. (I thought I read comments in the examples suggesting such a reduction would _not_ be retroactive).

- 7: Does "object security" apply to the "payload", or the "body"?
Can you describe or add a reference for the "usual considerations"?

Editorial:

- Abstract: That’s a really long abstract, and serves more as an introduction than an abstract. Please consider combining the first and last paragraph and leaving the rest to the introduction.

- 2.4, paragraph 5: a definition for "reassembler" would be helpful.

- Figures 5 and 6:
There's no discussion of either figure. Is that intentional?

   CoAP is based on datagram transports such as UDP, which limit the
   maximum size of resource representations that can be transferred
   without creating unreasonable levels of IP fragmentation.

CoAP is based on UDP, right? So isn't it?
NEW:
   CoAP is based on UDP datagrams, which limit the
   maximum size of resource representations that can be transferred
   without creating unreasonable levels of IP fragmentation.

And ...

OLD:
   Using fragmentation (either at the adaptation layer or at
   the IP layer) for the transport of larger representations would be
   possible up to the maximum size of the underlying datagram protocol
   (such as UDP),

NEW:
   Using fragmentation (either at the adaptation layer or at
   the IP layer) for the transport of larger representations would be
   possible up to the maximum size of the underlying datagram protocol
   (UDP),

Note that they might exist other instances.

No objection based on Jouni Korhonen's Gen-ART review. Thanks!

I agree with Stephen that the draft could read better if text duplication was reduced.

Thanks for adding new text at the beginning of the doc. This addresses my previous concern and makes it usage more clear from my point of view. Sorry for my rather long delay!

Please consider whether you need to say more about UDP usage for this extension than what the base CORE specification says - RFC 7252 has only one mention of RFC 5405, and that only points to guidance about reducing ACK_TIMEOUT below one second. I understand that the CoAP story includes "most of these nodes aren't capable of generating a lot of packets in a short timeframe", but does this extension make it easier to send multiple UDP packets back-to-back?

I'm reading this text, 

   In most cases, all blocks being transferred for a body (except for
   the last one) will be of the same size.  

and then this text

      *  The block size implied by SZX MUST match the size of the
         payload in bytes, if the M bit is set.  (SZX does not govern
         the payload size if M is unset).  For Block2, if the request
         suggested a larger value of SZX, the next request MUST move SZX
         down to the size given in the response.  (The effect is that,
         if the server uses the smaller of (1) its preferred block size
         and (2) the block size requested, all blocks for a body use the
         same block size.)
         
and realizing that I'm confused about why all the blocks for a body might NOT use the same block size. Maybe this doesn't matter (because an implementation would need to be prepared for the case when all the blocks don't use the same block size)?

The examples were helpful to me. Thank you for doing that work.

The intro and early section 2 has quite a bit of argument
as to why this design is good or better than some other.
For this reader, that's not really needed (I assume the WG
had those discussions). I think this is an example of a
recurring problem with the text here - with too many words,
clarity suffers. For example the Implementation note on p7
is, just by itself, the best and would be a sufficient
explanation of, the encoding, the description of which is
otherwise pretty opaque. There's also a good bit of
repetition that makes this a harder read in general. That's
all just IMO of course, and there may be history in the WG
that provides good cause for so many words to be needed.
All that said, I assume that it's too late to reduce the
size of this document, so no action is required unless the
authors/WG/chairs would themselves like to try remove
words.

Is there a specific reason that the 4.08 response code is overloaded for use for two different kinds of issues?

a) Mismatching Content-Format options in different blocks
b)  not all previous blocks are available at the server at the time of processing the final block of an atomic operation

Section 7.1:

Have you thought about how this text can be made actionable, especially in the case of atomic PUT or POST requests without maintaining state? If so, it would be good to elaborate here.

"Wherever possible, servers should therefore minimize the opportunities to create state for untrusted sources, e.g. by using stateless approaches."