Original text:
The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can, <del> e.g., be a counter or a pseudorandom number such as a hash.  The Initiator and the Responder also need to cache the old PRK_out until it has verfied that the other endpoint has the correct new PRK_out. </del>  I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate.

Reviewer comments:
Should be checked for conflicts with
I think fixing the comments above resolves conflict with , so can then be replaced by this.
This proposal for update in the key derivation description also addresses the clarifications requested in , thus replacing . We merge this to include it in -15 and enable further reviews.
This is not correct. How to derive and store PRKexporter is completely up to the implementation. One can derive PRKexporter everytime Exporter is called. This make it look like PRKout is overwritten. This should be formulated with and like TLS 1.3 or with and or something. How long to save the old keying material (PRKout, PRK_Exported, any derived keys) is likely up to the application. The importand thing is that they need to be deleted to give FS.
There was a request from someone that more guidance on the use of KeyUpdate should be expanded. Maybe not clear how you are supposed to alternate KeyUpdate and Exporter to get FS.
As you are considering making the KeyUpdate more detailed, I have a general design question. Are there use cases where one would expect Post-Compromise Security? That is, if one of the participant's PRK_out is compromised, a successful KeyUpdate mechanism between the two honest parties would heal them and lock out the attacker That is typically what is met by the double ratchet from the Signal app. The classical way to achieve that is roughly to have each party send out for the update fresh DH ephemeral shares, and add the corresponding DH secret inside the key derivation. (it would of course require more care than that in the details)
I think part of the plan is to make it less detailed and leave some stuff to the implementation/application :) The current KeyUpdate mechanism only gives forward secrecy. If you exchange some nonces and use them as a context you might get protection against an attacker is not monitoring all your traffic. I think details of this should be specified outside of EDHOC like in the OSCORE KeyUpdate draft in the CORE WG. The double ratchet was discussed in LAKE WG at an earlier point. The conclusion was that it added to much complexity to specify that as part of EDHOC. To get this kind of security an application has to rerun EDHOC frequently (like TLS 1.3). Signal uses the Diffie-Hellman ratchet very often which makes it understandable to have on optimized Diffie-Hellman ratchet post-handshake. Contrained use cases of EDHOC can not do Diffie-Hellman as often as Signal so it was determined that requiring rerun of the full EDHOC was the best tradeoff. Should the EDHOC specification say more about the benefits of frequently rerunning Diffie-Hellman? I don't remember how much it says. I recently wrote a paragraph about this that was accepted to RFC8446bis.
This is not correct. PRKout does not need to be stored. An implementation can derive the application keys directly and never store PRKout. An implementation can also store PRK_exporter if they don't use EDHOC-KeyUpdate.
This is not enough. You need to be sure that the old key is not needed more.
I merged which addresses some points raised in this issue. Please review and comment if there is anything missing.
No comments received, so I assume this is fine. (KeyUpdate is now in an appendix.)

Revised text:
The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can,  <ins> e.g., be a counter or a pseudorandom number such as a hash.  To provide forward secrecy the old PRK_out and derived keys must be deleted as soon as they are not needed.  When to delete the old keys and how to verify that they are not needed is up to the application. </ins> I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate.