Change:
to Machine Technical Specification LwM2M states that LwM2M servers MUST support the PSK mode of DTLS. <del> Use of PSK ciphersuites are optional when securing RADIUS RFC2865 with TLS as specified in RFC6614. </del> <ins> Securing RADIUS RFC2865 with TLS.  PSK ciphersuites are optional for this use case, as specified in RFC6614. </ins> <del> The Generic Authentication Architecture (GAA) defined by 3GGP mentions that TLS-PSK can be used between a server and user equipment for authentication GAA. </del> <ins> 3GPP server to user equipment authentication.  The Generic Authentication Architecture (GAA) defined by 3GGP mentions that TLS-PSK ciphersuites can be used between server and user equipment for authentication GAA. </ins> Smart Cards.  The electronic German ID (eID) card supports authentication of a card holder to online services with TLS-PSK SmartCard. <del> Quantum resistance: Some deployments may use PSKs (or combine them with certificate-based authentication as described in RFC8773) because of the protection they provide against quantum computers. </del> <ins> Quantum resistance.  Some deployments may use PSKs (or combine them with certificate-based authentication as described in RFC8773) because of the protection they provide against quantum computers. </ins> There are also use cases where PSKs are shared between more than two entities.  Some examples below (as noted by Akhmetzyanova et

Discussion:
While trying to find a home for this text, I did some other unrelated cleanup. I couldn't find a spot better than the security considerations. cc NAME
Slightly different placement than I suggested, but it works too.
From NAME This is a great point. We can add some language which describes considerations for external PSK reuse with early data.
Martin: I think we should add: When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that makes the keying material for the early data associated with one session different from the keying material for the early data associated win another session. As a result, when the external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data. However, this does not address the last point. Early data always has replay concerns. This was discussed at length during the development of RFC 8446. This is the reason that RFC 8446 says that clients "MUST only send early data which they deem safe to be replayed." With that warning in RFC 8446, what more needs to be said here?
Not sure what you mean regarding the last point, but this is a good contribution. How about (copy editing only):
That reads pretty well to me. Thanks, NAME
MT's text also looks good to me. I'm not sure I understand the (as-yet-unaddressed) point about anti-replay performance, though. I mean, I can parse it -- it's a claim that (some? all?) anti-replay implementations will incur more runtime cost than in scenarios where the PSK is reused and the random data is "not good enough". But how would that come to happen? Are we imagining an implementation that uses a hash table and inputs the client random as the hash input, and "not good enough" randomness would cause unbalanced hashing? Or is the nature of the concern on a totally different axis?
Yeah, I think that we can let that point lie. The NSS anti-replay implementation is somewhat vulnerable to hash stacking, but the effect is that early data is accepted less often, it's not that server CPU cycles are wasted.