Original text:
4.1.3.4. Observe RFC7641 is an optional feature.  An implementation MAY <del> support RFC7252 and the OSCORE option without supporting RFC7641. </del>  The Observe option as used here targets the requirements on forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1). <del> To support proxy operations, OSCORE MUST set Outer Observe.  If Observe was only sent encrypted end-to-end, an OSCORE-unaware proxy would not expect several responses to a request and notifications would not reach the endpoint.  Moreover, intermediaries are allowed to cancel observations at any time; forbidding this behavior would also result in notifications being dropped. An intermediary that supports Observe MUST copy the OSCORE option in the next hop request unchanged.  It is worth noting that although intermediaries are allowed to re-send notifications to other clients, when using OSCORE this does not happen, since requests from different clients will have different cache keys. </del>  In case of registrations or re-registrations, the CoAP client using Observe with OSCORE MUST set both Inner and Outer Observe to the same value (0).  This allows the server to verify that the observation was <del> requested by the client, thereby avoiding unnecessary overhead (processing and transmission of notifications) on the server, since such notifications would not benefit the client. Note that, as defined in Section 3.1 of RFC7641, the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE.  This means that several clients registering to the same protected resource via an intermediary, when using OSCORE, will be effectively registering to different target resources.  The intermediary may then register to the protected resource (different target resources) once per each client. The processing of the CoAP Code for Observe messages is described in coap-header. </del>  The Outer Observe option in the CoAP request may be legitimately <del> removed by a proxy or ignored by the server.  In these cases, the </del>  server processes the request as a non-Observe request and produce a non-Observe response.  If the OSCORE client receives a response to an Observe request without an Outer Observe value, then it verifies the

Reviewer comments:
This PR should (hopefully) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe. It should (hopefully) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used. A new appendix E is covering the latter case.

Revised text:
4.1.3.4. Observe RFC7641 is an optional feature.  An implementation MAY  <ins> support RFC7252 and the OSCORE option without supporting RFC7641, in which case the Observe related processing specified in this section, sequence-numbers and processing can be omitted. </ins> The Observe option as used here targets the requirements on forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1).  <ins> This section specifies Observe processing associated to the Partial IV (observe-partial-iv) and Observe processing in the presence of RFC7641-compliant intermediaries (observe-option-processing). In contrast to e.g. block-wise, the Inner and Outer Observe option are not processed independently.  Outer Observe is required to support Observe operations in intermediaries, but the additional use of Inner Observe is needed to protect Observe registrations end-to- end (see observe-option-processing). observe-without-intermed specifies a simplified Observe processing which is applicable in the absence of intermediaries. Note that OSCORE is compliant with the requirement that a client must not register more than once for the same target resource (see Section 3.1 of RFC7641) since the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE. 4.1.3.4.1. To support proxy operations, the CoAP client using Observe with OSCORE MUST set Outer Observe.  If Observe was only sent encrypted end-to-end, an OSCORE-unaware proxy would not expect several responses to a non-Observe request and notifications would not reach the client.  Moreover, intermediaries are allowed to cancel observations and inform the server; forbidding this may result in processing and transmission of notifications on the server side which do not reach the client. </ins> In case of registrations or re-registrations, the CoAP client using Observe with OSCORE MUST set both Inner and Outer Observe to the same value (0).  This allows the server to verify that the observation was  <ins> requested by the client, thereby avoiding unnecessary processing and transmission of notifications, since such notifications would not benefit the client. An intermediary that supports Observe MUST copy the OSCORE option in the next hop request unchanged.  Although intermediaries are allowed to re-send notifications to other clients, when using OSCORE this does not happen, since requests from different clients will have different cache keys. </ins> The Outer Observe option in the CoAP request may be legitimately  <ins> removed by a proxy or ignored by a server.  In these cases, the </ins> server processes the request as a non-Observe request and produce a non-Observe response.  If the OSCORE client receives a response to an Observe request without an Outer Observe value, then it verifies the