[Gen-art] Genart last call review of draft-ietf-core-stateless-05

[Dan Romascanu via Datatracker <[e-mail]>]

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.