I have no objection for this document. Many thanks to Rich Salz for his ARTART review.

Section 2:  For EAP, I thought the initiator was the server, and the responder was the peer.  The definitions here appear to be backwards.  Figure 1 in Section 3.1.1, seems to agree with my understanding, as does the rest of the draft.

Thanks for the work done in this document (I liked the use of SVG graphics, except for figure 7 though :-( ).

Nevertheless, section 3.1.4 contains `an anonymous NAI SHOULD be derived from the NAI in the certificate` without any guidance required by https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Same issue in section 3.5 `However, EDHOC error messages SHOULD be considered failure result indication,`

Section 4.1, s/indicates the length/indicates the length *in octets*/

Section 5: suggest adding the URL of the IANA registries as informative references.

Hi Dan, Rafael, Göran, John, and Francisco, 

Thank you for the effort put into this document. 

# I agree with Éric comments.

# I think Peer/Server roles would be better if introduced in the terminology section.

# Set ambiguity: clarify that this means set to 1

The text uses “set to 0”, “set to 1”, “set”, etc.

Some clarity can be done in the convention section by indicating how “set” should be interpreted.

Alternatively, consider changes such as:

OLD:
   The S flag bit SHALL be set in the EAP-EDHOC Start message sent by
   the EAP server to the peer.  The S flag bit SHALL NOT be set in any
   other EAP-EDHOC messages.  The M flag bit SHALL be set in all
   fragments except the last one.

NEW:
   The S flag bit SHALL be set to 1 in the EAP-EDHOC Start message sent by
   the EAP server to the peer.  The S flag bit SHALL NOT be set to 1 in any
   other EAP-EDHOC messages.  The M flag bit SHALL be set to 1 in all
   fragments except the last one.


OLD: The M bit (more fragments) is set on
NEW: The M bit (more fragments) is set to 1

There are many such occurrences.


# Future use

CURRENT:
  Values from 5 to 7 are not used in this specification.

Are these values reserved and available for future assignment? 

# You may find some nits that I flagged when reading the document [1].

Cheers,
Med

[1]  https://github.com/dangarciacarrillo/i-d-eap-edhoc/pull/14

Thank you to Ines Robles for the GENART review.

I support this document as an efficient way to improve the security/performance trade-off for low-resource devices.

One point I think should be clarified is this bit from Section 3.1:
>   Resumption of EAP-EDHOC may be defined using the EDHOC-PSK
>   authentication method [I-D.ietf-lake-edhoc-psk].

...compared to Section 6.9:
>   The cross-protocol attack of [RFC9190] does not apply here, as no
>   resumption mechanism has been defined for EAP-EDHOC.

I suggest 6.9 should be updated to more explicitly delegate responsibility to documents that define resumption mechanisms rather than just say it isn't this draft's responsibility.

Regarding Section 6.5:
>   EAP-EDHOC relies on EDHOC, which is designed to encrypt and integrity
>   protect as much information as possible.  Any change in any message
>   is detected by means of the transcript hashes integrity verification.

The statement that EDHOC is designed to "encrypt and integrity protect as much information as possible" (opportunistic) seems to be at odds with "any change in any message" (deterministic). As far as I can tell, the latter claim is true. Therefore, I would change how EDHOC is described here to match that. If in fact there are some changes that can be made to a message that cannot be detected, then the text needs corrected of course.