Draft: draft-ietf-lake-edhoc

Commentary: When does the Compliance requirements apply 
 The first term was " applicability statement " but since we did not intend the meaning of RFC 2026 was changed to " applicability template " which seems to be confusing because implies something needs to be filled in . New proposal : " application profile " . 
 I like it . That also aligns with the wording in TLS 1.3 . 
 Compliance requirements has some positive effects but also many negative . Constrained devices might be required to support things ( takes up storage ) they never use . Weaknesses might be found in cryptographic algorithms . Implementation then have to chose between being compliant or insecure . TLS 1.3 has softened the compliance requirements compared to TLS 1.2 ( COSE does not have any at all ) . TLS 1.3 ( RFC8446 ) use the following sentence " In the absence of an application profile standard specifying otherwise : " This might ( likely ? ) be a good sentence for EDHOC as well . 
 Other comments , in addition to the proposal in PR ( see above ): text for convenience : EDHOC may be : " In the absence of an applicability template specifying otherwise : " an initial sentence as in 2 . or PR 239 , the current text on cipher suites may be considerably simplified ( since it is anyway up to the application ) , for example : OLD For many constrained IoT devices it is problematic to support several crypto primitives . Existing devices can be expected to support either ECDSA or EdDSA .  suites 0 ( AES - CCM-16 - 64 - 128 , SHA-256 , 8 , X25519 , EdDSA , AES - CCM-16 - 64 - 128 , SHA-256 ) and 1 ( AES - CCM-16 - 128 - 128 , SHA-256 , 16 , X25519 , EdDSA , AES - CCM-16 - 64 - 128 , SHA-256 ) only differ in size of the MAC length , so supporting one or both of these is no essential difference . Similarly for cipher suites 2 ( AES - CCM-16 - 64 - 128 , SHA-256 , 8 , P-256 , ES256 , AES - CCM-16 - 64 - 128 , SHA-256 ) and 3 ( AES - CCM-16 - 128 - 128 , SHA-256 , 16 , P-256 , ES256 , AES - CCM-16 - 64 - 128 , SHA-256 ) . To enable as much interoperability as possible , less constrained devices SHOULD implement all four cipher suites 0 - 3 . Constrained endpoints SHOULD implement cipher suites 0 and 1 , or cipher suites 2 and 3 . Implementations only need to implement the algorithms needed for their supported methods . NEW  suites 2 ( AES - CCM-16 - 64 - 128 , SHA-256 , 8 , P-256 , ES256 , AES - CCM-16 - 64 - 128 , SHA-256 ) and 3 ( AES - CCM-16 - 128 - 128 , SHA-256 , 16 , P-256 , ES256 , AES - CCM-16 - 64 - 128 , SHA-256 ) only differ in size of the MAC length , so supporting one or both of these is no essential difference . An EDHOC - compliant implementation MUST implement cipher suite 2 and 3 . Implementations only need to implement the algorithms needed for their supported methods .
Paragraph (version A):
For many constrained IoT devices it is problematic to support several
crypto primitives.  Existing devices can be expected to support
either ECDSA or EdDSA.  Cipher suites 0 (AES-CCM-16-64-128, SHA-256,
8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) and 1 (AES-CCM-
16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256)
only differ in size of the MAC length, so supporting one or both of
these is no essential difference.  Similarly for cipher suites 2
(AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-
256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-
16-64-128, SHA-256).  To enable as much interoperability as possible,
less constrained devices SHOULD implement all four cipher suites 0-3.
Constrained endpoints SHOULD implement cipher suites 0 and 1, or
cipher suites 2 and 3.  Implementations only need to implement the
algorithms needed for their supported methods.
Paragraph (version B):
Implementations MUST support cipher suite 2 and 3.  Cipher suites 2
(AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-
256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM-
16-64-128, SHA-256) only differ in size of the MAC length, so
supporting one or both of these is no essential difference.
Implementations only need to implement the algorithms needed for
their supported methods.