Original text:
suites can be identified with any of the four values -24, -23, -22, -21. <del> The following cipher suites are for constrained IoT where message overhead is a very important factor: The following cipher suite is for general non-constrained applications.  It uses very high performance algorithms that also are widely supported: The following cipher suite is for high security application such as government use and financial applications.  It is compatible with the CNSA suite CNSA. </del>  The different methods use the same cipher suites, but some algorithms are not used in some methods.  The EDHOC signature algorithm is not

Reviewer comments:
Looks good. One inconsistency is that there is no cipher suite with AES-GCM and NIST curves, like (A128GCM, SHA-256, P-256, ES256, A128GCM, SHA-256). This could be a new cipher suite 5. Then all non-CNSA suites would come in pairs.
That is very intentional. The GCM cipher suite uses X25519 for key exchange and ECDSA for authentication. This seems to be the dominant choice for HTTPS on the Web. Unless you are constrained you typically use X25519 for key exchange for speed and ECDSA for authentication as that is what the CAs support. For an IoT device you probably want to have a single curve implemented. Also it might be much easier to switch to EdDSA as you might not have to rely on Global CAs and all other HTTPS nodes to support EdDSA. You can just deploy you own CWT server and make sure the nodes in you new IoT deployment support EdDSA. I have not heard any IoT people very interested in GCM. People seems far more interested in ChaCha20.
Ready to merge?
Is it worth having 4 diiference CCM based ciphser suites. And are they the correct 4?EDHOC should probably have a ChaCha20-Poly1305 cipher suite from start. Probably with SHA-256. X25519 and EdDSA.The CNSA cipher suite does not really need a 1 byte value. Could live with 2 byte value.
-Agreement during interim is that the 4 different CCM are all needed and that they are the correct ones. -ChaCha20 should be combined with both P-256 and X25519 -CNSA suite can have two bytes.
I think we should specify a X448/SHAKE256 suite to complement the CNSA suite.
The GCM suite is chosen to match what is currently used on the web which is X25519 combined with P-256 ECDSA. Not sure we need to specify anything else here. IoT community seems more interested in ChaCha20 than GCM. ~~
URL
Resolved with .

Revised text:
suites can be identified with any of the four values -24, -23, -22, -21.  <ins> The following CCM cipher suites are for constrained IoT where message overhead is a very important factor.  Cipher suites 1 and 3 use a larger tag length (128-bit) in the EDHOC AEAD algorithm than the Application AEAD algorithm (64-bit): The following ChaCha20 cipher suites are for less constrained applications and only use 128-bit tag lengths. The following GCM cipher suite is for general non-constrained applications.  It uses high performance algorithms that are widely supported: The following two cipher suites are for high security application such as government use and financial applications.  The two cipher suites do not share any algorithms.  The first of the two cipher suites is compatible with the CNSA suite CNSA. </ins> The different methods use the same cipher suites, but some algorithms are not used in some methods.  The EDHOC signature algorithm is not