Reviewer: Dan Romascanu 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 treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-core-stateless-05 Reviewer: Dan Romascanu Review Date: 2020-04-01 IETF LC End Date: 2020-04-02 IESG Telechat date: Not scheduled for a telechat Summary: READY with Issues. This is a very clear and well-written document. I have a few minor issues that I suggest to clarify before approval and publication. Major issues: Minor issues: 1. It would be useful to include some considerations whether the authors consider useful / possible / allowed that the mechanism (extended token lengths) presented in this document can be used for other purposed than the by-design the use case (avoiding per-request state). 2. In Section 2.2: > The idea is that a server implementing this document should at least support large tokens in its first few processing steps, enough to return an error response rather than a Reset message. Why is not this 'should' capitalized? What happens if the server does not support large tokens in the first processing steps? 3. In Section 5.2: > The use of encryption, integrity protection, and replay protection of serialized state is recommended in general, unless a careful analysis of any potential attacks to security and privacy is performed. AES- CCM with a 64 bit tag is recommended, combined with a sequence number and a replay window. Where encryption is not needed, HMAC-SHA-256, combined with a sequence number and a replay window, may be used. A few issues with this paragraph. Why are not 'recommended' and 'may' capitalized? The formulation 'is recommended in general' seems odd, and the rest of the sentence does not clarify. What does 'a careful analysis of any potential attacks' mean? Who is supposed to perform this analysis and who can ensure it is 'careful enough' at any given point in time for any potential attacks? Nits/editorial comments: 1. I do not believe there is a need to mention in the Abstract that 'This document updates RFCs 7252 and 8323.'. This is shown in the header of the text on the front page, and also is part of the metadata. 2. Are the message formats defined in Appendix A for different transports considered normative or examples? It would be useful to specify. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
