Last Call Review of draft-ietf-core-block-18
review-ietf-core-block-18-opsdir-lc-wu-2015-12-04-00

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 with the intent of improving the operational
 aspects of the IETF drafts. Comments that are not addressed in last call may
 be included in AD reviews during the IESG review.  Document editors and WG
 chairs should treat these comments just like any other last call comments.



By extending basic CoAP with two block options and two block sized, this
document provides a mechanism to transfer larger representations in a
block-wise fashion. It is well written,
 especially security section. In addition, Several examples are provided to
 show how to use block options. Interaction between CoAP and HTTP and
 interaction between Block option and other options and aspects are also
 discussed. I think this document is ready for publication. Here are a few
 editorial comments:

1.



Section 2, 2nd paragraph

Section 2 said

“

In identifying these options, we use the number 1 to refer to the

   transfer of the resource representation that pertains to the request,

   and the number 2 to refer to the transfer of the resource

  representation for the response

”

Where to encode number 1 and number 2 for two separate options?

2.



Section 3.1, 1st paragraph

“

The first example (Figure 2) shows a GET request that is split into

three blocks.  The server proposes a block size of 128, and the

client agrees.  The first two ACKs contain 128 bytes of payload each,

and third ACK contains between 1 and 128 bytes.

“

s/”128 bytes of payload”/” payload of 128 bytes”

s/”between 1 and 128 bytes”/”payload between 1 and 128 bytes”

3.



Section 3.1, figure 2

Is MID abbreviation of “Message ID”, would you like to expand it?

4.



Section 4, 2

nd

 paragraph

s/is already/has already

5.



Section 4, 2

nd

 paragraph

Since Size1 has already defined in [RFC7252], I am wondering whether this draft
need to update RFC7252 since it looks Size1 is redefined in this draft. Is
there any update to IANA section for Size1 registry?

6.



General comment:

Is there possible to provide an example to show how to use block size together
with block option?



Cheers!

-Qin Wu