Change:
(METHOD_CORR mod 4) equals 0 or 1 then C_x is set to C_R, else C_x is omitted. <del> ERR_CODE - error code encoded as an integer. </del> <ins> ERR_CODE - error code encoded as an integer.  The value 0 is used for success, all other values (negative or positive) indicate errors. </ins> ERR_INFO - error information.  Content and encoding depend on error code. The remainder of this section specifies the currently defined error <del> codes, see fig-error-codes.  Error codes 1, 0 and -1 MUST be supported.  Additional error codes and corresponding error information may be specified. </del> <ins> codes, see fig-error-codes.  Error codes 1 and 2 MUST be supported. Additional error codes and corresponding error information may be specified. </ins> 6.1. <del> TBD </del> <ins> Error code 0 MAY be used internally in an application to indicate success, e.g. in log files.  ERR_INFO can contain any type of CBOR item.  Error code 0 MUST NOT be used as part of the EDHOC message exchange flow. </ins> 6.2. <del> Error code 0 is used for unspecified errors and contain a diagnostic message. For error messages with ERR_CODE == 0, ERR_INFO MUST be a text string containing a human-readable diagnostic message written in English. The diagnostic text message is mainly intended for software engineers that during debugging need to interpret it in the context of the EDHOC specification.  The diagnostic message SHOULD be provided to the calling application where it SHOULD be logged. </del> <ins> Error code 1 is used for errors that do not have a specific error code defined.  ERR_INFO MUST be a text string containing a human- readable diagnostic message written in English.  The diagnostic text message is mainly intended for software engineers that during debugging need to interpret it in the context of the EDHOC specification.  The diagnostic message SHOULD be provided to the calling application where it SHOULD be logged. </ins> 6.3. <del> Error code 1 MUST only be used in a response to message_1 in case the </del> <ins> Error code 2 MUST only be used in a response to message_1 in case the </ins> cipher suite selected by the Initiator is not supported by the Responder, or if the Responder supports a cipher suite more preferred by the Initiator than the selected cipher suite, see resp-proc-msg1. ERR_INFO is of type SUITES_R: If the Responder does not support the selected cipher suite, then

Discussion:
This should address all open issues regarding errors. Align with very common standard that 0 means success and everything else means error Specify that success is for internal use in the application, it therefore makes sense to use any and let the application define what to store. No sense in forcign application to support 0, it is not needed for interoperability over the wire.
I kept error codes positive as proposed by IOTOPS, but changed the more general error "unspecified" comes before the more specific "wrong ciphersuite" because that allows for more specific errors to follow in a structured way in the table that aligned better with the subsubsections describing the cipher suite negotiation.
John and I are happy with this now. Unless there are any comments we will soon merge this.
Looks good.
At the last interim there was a suggestion to standardize classes of error messages and to ask the IoT groups in IETF about what classes of error messages that should be standardized. The error message should then be augmented with a error message class. int? array of int? Shoudl the optional text string remain. That cannot be used for any automation. But might be useful for loggging for later reading by a human. The initial classes or error message might not provide much info, e.g. "authentication error"
Mailthread in iotops: URL
Proposal after discussion in Hackathon: error = ( ? Cx : bstridentifier, DIAGMSG : tstr, ERRCODE : int / 2 int, ? SUITESR : [ supported : 2 suite ] / suite, ) Top-level ERRCODEs: (0. Success) Message field error (syntax error or incorrect protocol field of expected message) Selected cipher suite not supported (include SUITES_R in message) Credential/context error (error related to establish certificate/raw public key context for processing message, including certificate expired, revoked, unsupported, corrupt, unknown CA, or other issue in processing the credential) Decrypt error (a cryptographic operation failed, including being unable to correctly verify a signature or a MAC in the protocol message) Auxiliary data error (unsupported or missing auxiliary data) Access denied (credential valid but peer not allowed access) Internal error (error not related to the protocol or the peer) Selected comments during Hackathon: Relation to errors on other layer, e.g. CoAP errors or error in application.

- EDHOC does not require CoAP so could have use for specified own errors. - Does "5. AD error" belong to EDHOC? Perhaps, auxiliary data provides means for security applications to reuse EDHOC and this would be a channel to send errors in those applications. [Not sure if this helps but, alternatively, errors could be encoded as auxiliary data, which may require an AD-field in the error message] - Does "6. Access denied" belong to EDHOC? Perhaps, it provides a suitable error to the requirement "Verify that the identity of the Responder is an allowed identity for this connection" Further comments are welcome. Happy to make the list shorter if possible.
Other thoughts: We can put some of these error classes into an "x. unspecified error" bucket if we don't think they are not meaningful to act upon individually. We can define a class of errors "y. general error" and allow implementations to use class y for any error, including those properly belonging to some class above. This would allow implementations to only support some of the specified errors above, potentially listed in the applicability statement. (That would render the list of classes above just a RECOMMENDATION.)
Many OSs, shells, and programming languages (e.g. C) use 0 for success and everthing non-zero (negative or positive) is considered an error. HTTP and Coap use postive numbers only where 2. or 2xx is considered success. I think we should probably follow one of these convensions instead of making a new one. The specification should also probably define that everything else than whatever we decide for success is considered an error.
I made a PR addressing all known issues regarding this.
This is ready to merge unless there are any objections.
The PR has been discussed and merged. Closing Hello IOTOPS, There is a discussion in the LAKE WG regarding the potential need to standardize error messages appearing in a security handshake protocol targeting IoT devices. Is this something IOTOPS could contribute to and/or review? Assuming this might be the case, here is a background and some draft error categories for discussion. Background: LAKE is specifying a lightweight authenticated Diffie-Hellman exchange called EDHOC [1] similar to the TLS 1.3 handshake but targeting constrained IoT.

The protocol consists of 3 messages and an error message which may be sent in response to any non-error message. The error message essentially consists of a diagnostic message field containing a text string targeting the peer administrator. All errors are fatal and cause the protocol to discontinue. The intent with the error message is to provide a hint about the error to the peer application, to enable logging of errors and appropriate management operations. (Note that since the protocol failed to establish security the error message is unprotected and needs to be treated accordingly.) The question is what error messages need to be standardized, if any. Detailed information can be provided by using the diagnostic text string. But standardizing detailed error information adds complexity to the specification and implementation, which would contradict one of the design objectives. But perhaps we can we identify a small set of error categories (codes) that require to be singled out, for example because how they impact operations. Such categories could potentially be complemented with text providing additional details. Please find below a first sketch of error categories (inspired by error alerts from TLS 1.3 [2]). Two questions (going in opposite directions): Do we need to make more distinctions/are there missing error categories? Are these distinctions necessary, or can we remove/group together some of them? Draft error categories: A. message field error (syntax error or incorrect protocol field) B. integrity error (unable to correctly verify a signature or a MAC) C. credential error (error related to the attempt to use a certificate/raw public key as a basis for autentication, e.g., certificate expired, revoked, unsupported, corrupt, unknown CA etc.) D. access denied (credential valid but peer not allowed access) E. internal error (error not related to the protocol or the peer) F. auxiliary data error (unsupported or missing extension) G. cipher suite not supported (this particular error has already been specified with a special message field, see Section 6) Any comments are welcome. Thanks Göran [1] URL [2] URL