Original text:
is not applicable to the approach defined in this specification. If step 4 (EDHOC processing) fails, the server discontinues the <del> protocol as per Section 5.4.3 of I-D.ietf-lake-edhoc and sends an EDHOC error message, formatted as defined in Section 6.1 of I-D.ietf- lake-edhoc.  In particular, the CoAP response conveying the EDHOC error message: MUST have Content-Format set to application/edhoc defined in Section 9.5 of I-D.ietf-lake-edhoc. MUST specify a CoAP error response code, i.e. 4.00 (Bad Request) in case of client error (e.g. due to a malformed EDHOC message_3), or 5.00 (Internal Server Error) in case of server error (e.g. due to failure in deriving EDHOC key material). </del>  If step 4 (EDHOC processing) is successfully completed but step 7 (OSCORE processing) fails, the same OSCORE error handling applies as defined in Section 8.2 of RFC8613. <del> 5. </del>  <del> An example based on the OSCORE test vector from Appendix C.4 of RFC8613 and the EDHOC test vector from Appendix B.2 of I-D.ietf-lake- edhoc is given in fig-edhoc-opt-2.  In particular, the example assumes that: </del>  The used OSCORE Partial IV is 0, consistently with the first request protected with the new OSCORE Security Context. <del> The OSCORE Sender ID of the Client is 0x20.  This corresponds to </del>  the EDHOC Connection Identifier C_R, which is encoded as the <del> bstr_identifier 0x08 in EDHOC message_3. </del>  <del> The EDHOC option is registered with CoAP option number 13. </del>  6.

Reviewer comments:
Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).

Revised text:
is not applicable to the approach defined in this specification. If step 4 (EDHOC processing) fails, the server discontinues the  <ins> protocol as per Section 5.4.3 of I-D.ietf-lake-edhoc and responds with an EDHOC error message, formatted as defined in Section 6.1 of I-D.ietf-lake-edhoc.  In particular, the CoAP response conveying the EDHOC error message MUST have Content-Format set to application/edhoc defined in Section 9.5 of I-D.ietf-lake-edhoc. </ins> If step 4 (EDHOC processing) is successfully completed but step 7 (OSCORE processing) fails, the same OSCORE error handling applies as defined in Section 8.2 of RFC8613.  <ins> 5.4. </ins>  <ins> fig-edhoc-opt-2 shows an example of EDHOC + OSCORE Request, based on the OSCORE test vector from Appendix C.4 of RFC8613 and the EDHOC test vector from Appendix B.2 of I-D.ietf-lake-edhoc.  In particular, the example assumes that: </ins> The used OSCORE Partial IV is 0, consistently with the first request protected with the new OSCORE Security Context.  <ins> The OSCORE Sender ID of the Client is 0x00.  This corresponds to </ins> the EDHOC Connection Identifier C_R, which is encoded as the  <ins> bstr_identifier 0x37 in EDHOC message_3. </ins>  <ins> The EDHOC option is registered with CoAP option number 21. </ins> 6.