Change:
To prevent reuse of an AEAD nonce with the same AEAD key, or from accepting replayed messages, an endpoint needs to handle the situation of losing rapidly changing parts of the context, such as <del> the Sender Sequence Number, Replay Window, and Notification Numbers. These are typically stored in RAM and therefore lost in the case of e.g. an unplanned reboot.  There are different alternatives to recover, for example: </del> <ins> the Sender Sequence Number, and Replay Window.  These are typically stored in RAM and therefore lost in the case of e.g. an unplanned reboot.  There are different alternatives to recover, for example: The endpoints can reuse an existing Security Context after updating the mutable parts of the security context (Sender Sequence Number, and Replay Window).  This requires that the mutable parts of the security context are available throughout the lifetime of the device, or that the device can recover security context data based on careful use of non-volatile memory, see seq- numb and reboot-replay for an example.  If an endpoint makes use of a partial security context stored in non-volatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages. The endpoints can only update the server's Replay Window by using the Echo option I-D.ietf-core-echo-request-tag, see reboot-replay for an example.  This method only updates the Replay Window and does not update the server's Sender Sequence Number, so it MUST be complemented by a method for updating the Sender Sequence Number (e.g. by using seq-numb) if the application allows for the server to encode the AEAD nonce using its Sender Sequence Number in responses to regular requests, or if the server supports Observe. This method MUST NOT be used if the client can not guarantee non- reuse of its own Sender Sequence Numbers (e.g. by using seq-numb). The endpoints can reuse an existing shared Master Secret and derive new Sender and Recipient Contexts, see master-secret- multiple for an example.  This typically requires a good source of randomness. The endpoints can use a trusted-third party assisted key establishment protocol such as I-D.ietf-ace-oscore-profile.  This requires the execution of three-party protocol and may require a good source of randomness. </ins> The endpoints can run a key exchange protocol providing forward secrecy resulting in a fresh Master Secret, from which an entirely new Security Context is derived.  This requires a good source of randomness, and additionally, the transmission and processing of <del> the protocol may have a non-negligible cost in terms of, e.g., </del> <ins> the protocol may have a non-negligible cost, e.g. in terms of </ins> power consumption. <del> An alternative is to use a trusted-third party assisted key establishment protocol such as I-D.ietf-ace-oscore-profile, which may be more lightweight and may not require additional randomness. The endpoints can reuse an existing shared Master Secret and derive new Sender and Recipient Contexts.  This typically requires a good source of randomness and a message exchange, but not as large performance impact as a key exchange protocol, and no trusted third party.  See master-secret-multiple for an example. Under certain circumstances an endpoint can reuse an existing Security Context with updated Sender Sequence Number, Replay Window, and Notification Numbers.  This requires that the mutable parts of the security context are available throughout the lifetime of the device, or that the device can recover security context data based on careful use of non-volatile memory, see master-secret-once for an example.  If an endpoint makes use of a partial security context stored in non-volatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages. The choice of method may depend on capabilities of the devices deployed and the solution architecture.  This document RECOMMENDS the use of a key exchange protocol. </del> <ins> The endpoints need to be configured with information about which method is used.  The choice of method may depend on capabilities of the devices deployed and the solution architecture.  Using a key exchange protocol is necessary for deployments that require forward secrecy. </ins> 8.

Discussion:
According to NAME 's comments: remove notification numbers changed the order of the list added one method: use of echo to update replay window (when server does not uses its own sender sequence number in responses) editorial (Jim apparently I cannot ask you to review via github, maybe because you are not part of the CoRE WG github organization? But yes, if you could check that this answers your comments, that'd be great)
I reviewed and made the following changes: Jim's method move as number 2 Some clarifications of that method Changing motivations which made less sense when the methods were is reverse order Moved the details of Jim's method to B.1 where other detailed methods are Grouped non-volatile methods under one heading in appendix B, and changed reference (So I violated the name of this PR since it extends to appendix B.1)