The document defines enhancements for the CoAP protocol that close a
number of security issues. Operationally most relevant is likely the
Echo option, which can help to reduce the abuse of CoAP for DDoS
amplification. The proposed Request-Tag	option resolve ambiguities
with block transfers and as such is most relevant for some CoAP
applications but less so for the Internet as a whole.

The document is well written, it was a pleasure to read it. I believe
the document is ready to be published except two nits that confused
me while reading through the document:

- The number of 152 bytes mentioned in section 2.4:

  3*152 would be 456 octets, I am not sure why this is the "typical
  size of a frame on the wire sent across the Internet". Either
  explain how you obtained this number of consider removing it in case
  it does depend on assumptions that are not guaranteed to be always
  true. One option could also be to simply drop this sentence.

- The difference between Figure 2 and Figure 3 is rather subtle.

  I actually diffed the figures to find it. My understanding is that
  it is really only the labels t0 and t1 and e0 and e1. One could
  perhaps change the figures to make it more explicit when t0 (e0)
  take place, perhaps also clarifying the text a bit. There is perhaps
  some confusion caused by the notion of time t0, t1, the notion of
  events e0, e1, and the notion of tag values labeled (t0) and (e0).
  The text says "The server verifies freshness by checking that e0
  equals e1, where e0 is the cached value when the Echo option value
  was generated, and e1 is the cached value at the reception of the
  request." I found this confusing. It think what you are trying to
  say is that the tag value cached at event e0 is the same as the tag
  value received at event e1, no?