I think it is good that we label this as an example.

I propose to remove when to send error messages and when to discontinue from this text. When to send error messages is subject to DoS considerations and complicates the example. These actions are described elsewhere in the draft and can without loss of information be omitted here.

In the previous description I found it hard to distinguish between WAIT_M2 and RCVD_M2:

If a candidate message_2 is received we are still in WAIT_M2, because if processing fails we are transitioning from WAIT_M2 to ABORTED. So (after several versions) I added a state VRFD_M2, to distinguish between a message received and a message verified. It also enables a distinction between having decrypted message_2 (and obtained ID_CRED_R) and having verified the message with CRED_R.

To simplify the description after COMPLETED I separated the cases of message_4 or not with separate paragraphs in the text. This is known to the Initiator by the application profile.

Have a look at the result. If this works, I can make the same change for the Responder section.

Have a look at the result. If this works, I can make the same change for the Responder section.

I think it looks and reads really nice!

@malishav @marco-tiloca-sics Please read the whole appendix again.

Edit: Note one more commit on the last paragraph:

@gselander This looks good and I like how you split the handling of error vs invalid messages with new states. I am only thinking whether transition names should be in present tense to denote actions: s/sent message/send message; s/received message/receive message; s/verified message/verify message

@malishav Fixed, have a look.

@dnav You commented on this at IETF 115. Could you please review this new appendix and see if it addresses your concerns?

https://github.com/lake-wg/edhoc/pull/373/files

@marco-tiloca-sics Please read the whole appendix again.

Looks good to me, thanks!

@dnav You commented on this at IETF 115. Could you please review this new appendix and see if it addresses your concerns?

https://github.com/lake-wg/edhoc/pull/373/files

This looks goos to me.

My concerns were that a state machine could be seen as a second source of truth instead of just an example. I am relieved by the way it is presented here.

Note that now I want to rename my implementation states to WAIT_M2, RCVD_M2, etc. And I guess that during interoperability testings, people will refer to these states. This is not a bad thing.

Regards,

Thanks @dnav - no, you don't have to change your implementation states :-)

No further comments received, merging now.