Original text:
Observe RFC7641 is an optional feature.  An implementation MAY support RFC7252 and the OSCORE option without supporting RFC7641, in <del> which case the Observe related processing specified in this section, sequence-numbers and processing can be omitted. The Observe option as used here targets the requirements on forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1). 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. </del>  <del> 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. </del>  <del> 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. 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 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. The Outer Observe option in the CoAP request may be legitimately removed by a proxy or ignored by a server.  In these cases, the 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 response as a non-Observe response, as specified in ver-res.  If the OSCORE client receives a response to a non-Observe request with an Outer Observe value, it stops processing the message, as specified in ver-res. </del>  In order to support Observe processing in OSCORE-unaware intermediaries, for messages with the Observe option the Outer Code <del> SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for </del>  responses.  4.1.3.4.2. If the server accepts an Observe registration, a Partial IV MUST be

Reviewer comments:
Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported

Revised text:
Observe RFC7641 is an optional feature.  An implementation MAY support RFC7252 and the OSCORE option without supporting RFC7641, in  <ins> which case the Observe related processing can be omitted. </ins>  <ins> OSCORE supports a reduced set of RFC7641 operations performed in intermediary nodes as specified in this section.  The use of Observe targets the requirements on forwarding of Section 2.2.1 of I- D.hartke-core-e2e-security-reqs, i.e. that observations go through any intermediate node, as illustrated in Figure 8 of RFC7641). </ins>  <ins> Inner Observe is used by default to protect the value of the Observe option between the endpoints.  Outer Observe is additionally used to support a selected set of intermediate node operations that are useful while maintaining end-to-end security.  Intermediary nodes MUST copy the OSCORE option in the next hop request unchanged. </ins> In order to support Observe processing in OSCORE-unaware intermediaries, for messages with the Observe option the Outer Code  <ins> MUST be set to 0.05 (FETCH) for requests and to 2.05 (Content) for </ins> responses. <ins> 4.1.3.4.1. The client MUST set both Inner and Outer Observe to the same value in the request.  In order to support the case of an intermediary node ignoring a registration request (Observe 0) and instead processing a non-Observe request (Section 2 of RFC7641), the server MUST only consider the received message a registration request if both Inner and Outer Observe are set to 0. Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the Partial IV (and thus the payload and OSCORE option) change.  The server uses the Partial IV of the new request as the 'request_piv' of new responses. Since intermediaries are not assumed to have a security context with the server, cancellation or re-registration of an observation initiated by an intermediary node is not supported. Cancellation of observation by an intermediary using the Reset message as response to a notification can still be applied. An intermediary node may forward a re-registration message, but if a proxy re-sends an old registration message from a client this will trigger the replay protection mechanism in the server which, depending on action, may result in a termination of the observation in proxy or client.  An OSCORE aware intermediary SHALL NOT initiate re-registrations of observations.  A server MAY respond to a replayed registration request with a cached notification.  The server SHALL NOT respond to a replayed registration request with a message encrypted using the Partial IV of the request. 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. </ins> 4.1.3.4.2. If the server accepts an Observe registration, a Partial IV MUST be