Reviewer: Christer Holmberg Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-core-cocoa-03 Reviewer: Christer Holmberg Review Date: 2018-03-16 IETF LC End Date: None IESG Telechat date: 2018-04-05 Summary: >From a technical perspective I don’t have any issues. However, I think the document could use quite a bit of editorial improvements. There is lots of inconsistent terminology, “speech-to-text” etc. I will focus on parts that I think are unclear. Major issues: N/A Minor issues: N/A Nits/editorial comments: --- General: The document uses lots of different, and often complicated, terminology for referencing RFC 7252. Example: “In the definition of the CoAP protocol [RFC7252],…” “The CoRE CoAP specification defines…” Etc etc. Please use consistent terminology. I suggest to simply say “CoAP [RFC7252]” or “[RFC7252]”. --- General: In some places the text says: “The present specification…” I suggest to say: “This specification…” --- General: The draft uses “CoAP endpoint” and “endpoint” terminology. Please use consistent terminology. --- General: The draft uses “RTO estimator” and “estimator” terminology. Please use consistent terminology. Also, what is an “RTO estimator”? --- General: Some of the sections are named “Discussion”. However, they still contain normative procedures, and even RFC2119 terminology (MUST, SHOULD etc). Because of that, I think it is more than a discussion. A discussion is typically used to justify something, or to give some background, not to define procedures. --- The Abstract and the Introduction say: “CoAP, the Constrained Application Protocol, needs to be implemented in such a way that it does not cause persistent congestion on the network it uses.” What exactly does this mean? Implemented in what way? --- The text in Section 2 says: “The present specification is based on the approved text in the [RFC7252] base specification.” I don’t understand the “approved” part. Since RFC 7252 has been published, I assume the text is approved :) --- The text in Section 3 refers to “Responder”. However, it is not defined/referenced anywhere. --- The text in Section 4.3 says: “The state of the RTO estimators for an endpoint SHOULD be kept as long as possible.” Later the text says that the RTO state depends on whether there is other state (DTLS etc) or not? Can the sentence above be removed? --- The text in Section 4.3 says “very strongly RECOMMENDED” and “strongly RECOMMENDED”. That sounds like a “SHOULD” in my ears :) --- The text in Section 4.3 talks about “State of RTO estimator” and “RTO state”. Are these different states? --- The text in Section 5 talks about “non-confirmables”. Please include a reference or definition. --- The text in Section 7 says: “The security considerations of, e.g., [RFC5681], [RFC2914], and [RFC8085] apply. Some issues are already discussed in the security considerations of [RFC7252].” I don’t think you can say “e.g.,” and “Some issues”. It needs to be clear which security considerations apply.
