Hello, I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready with nits This document proposes an improved congestion control for CoAP. Its Security Considerations section lists several RFCs whose security discussion may apply, and in particular [RFC7252]. This is a bit annoying as the security considerations section of RFC 7252 is 6 pages long. What do you mean more precisely? What should the implementer care about? Otherwise I agree with the authors that attacks preventing the delivery of some packets are hard to prevent while seriously impacting CoCoA. Such attacks are however limited to a single flow. What about the opposite (misleading the sender and making him unresponsive to congestion signals)? This would be a more serious issue. This is not specific to CoAP but could CoAP simplify this type of attack? Other comments: ** Introduction: In sentence "For non-confirmable packets, it also limits the sending rate to 1/RTO;" I have problems understanding what "non-confirmable" means. ** Section 3: When saying that "CoCoA has been found to perform well in scenarios with latencies ranging from the order of milliseconds to peaks of dozens of seconds,..." what do you mean by "latency"? Is it the transmission and/or propagation times? Is it related to the access method? Not very clear. And I'm a bit surprised by the value of "dozens of seconds »? Is it just a simulation parameter or is it realistic. ** Section 3: (corollary) the default initial RTO is set to 2 to 3 seconds, i.e., well below the "dozens of seconds" mentioned above. ** Appendix B. Pseudocode: As a general comment, I don't like function definitions where input and output are not defined, where global versus local variables are not defined, where persistant variables (global or static local variables) are not defined. For instance, between two calls to updateRTO(), should the RTO variable keep its previous value (I assume it is the case) or not? Same question for RTTVAR_strong, RTT_strong. And in appendix B.1., since you provide C-type pseudo-code, it's better to use a final ";" during default value initialisation (or #define if this is a constant). Cheers, Vincent