Reviewer: Jürgen Schönwälder Review result: Has Nits 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? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
