Change:
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 MUST verify the response as a non-Observe response. <del> If the OSCORE client reveives a response to a non-Observe request </del> <ins> If the OSCORE client receives a response to a non-Observe request </ins> with an Outer Observe value, the processing is covered in processing. <ins> 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 observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and Object- Security option) change.  The server uses the new request's Partial IV as the "request_piv" of new responses. </ins> 4.2.3.5. The Object-Security option is only defined to be present in OSCORE

Discussion:
as discussed some hours ago. Notes about proxies go to the mailing list for further routing. Closes: URL
The mailing list discussion that the kind of extension is not covered by observation. Could you try to sit together with Klaus to talk this out? (I'd be happy to join in, but as both all of you and Klaus are in Singapore right now, you might want to grab any short-term occasion to talk to the man who wrote the boo^WRFC on observation)
There is no mention of observation renewal (cf. ) in OSCORE, and I think there should be, because there are two possible interpretations, hinging on "All options MUST be identical to those in the original request except for the set of ETag Options": The ETag is encoded in the message, thus the message may change and be encrypted with a new nonce. There is no ETag in an OSCORE observe, therefore the only valid renewal is renewal with the very message with the same nonce (it's not nonce reuse when the message is identical) can be sent. Either is consistent with the current text; option 2 would be the easy path because the text addition would just say that "Renewal of the observation and updating of the ETags is not supported at OSCORE level. The underlying transport's observation can be renewed, but its Object-Security options and FETCH payload can not be different from the original request". Advantages of 1: The set of ETags can be updated as with regular Observation. A new request PartIV is sent to the server, so the client can have freshness of new messages relative to the renewal operation without stopping the observation and starting a new one. Disadvantages of 1: A proxy might be tripped up by an option that is not an ETag changing in an update. (Though it shouldn't, really -- given that the observation cancellation could have been lost, it should just view such an event as the cancellation of an old and the establishing of a new observation, and forward it accordingly.) Nonce ambiguity: The client needs to be prepared to receive updates with the old nonce (which would read as AEAD decryption failures) after having renewed an observation, and mustn't be upset by them (read: must not send anything back to the server that would jeopardize the observation).

I think I'd prefer 1, but would be fine with either given the ambiguity-of-nonce point.
I don't understand the concept of observe renewal. I have always treated this as a new observe and not as a renewal.
I'd describe observe renewal as another Request message on the same token that should elicit a more immediate response to confirm that the observation is still on (and if it wasn't, register one anew transparently). It is practically answered either by a piggybacked ACK 2.05 Content, or by an empty ACK, in which case there is no message that's explicitly "the" response to the refresh, but the client will still expect something back on that token within however long it is ready to wait for an initial response. That one can update the set of ETags while doing so is a practical feature and at the same time an extreme load the request/response model (now not only can an exchange have multiple responses, it can also have multiple requests), so I prefer to read it as the second request implicitly canceling the first silently ("The token was re-used, so obviously it has been retired by the client") and establishing a new observation, which is so much easier on the request/response model and looks exactly the same on the wire. (Those considerations also made me propose 1). Christian Amsüss wrote: It's not the client alone who decides when a token is no longer in use. Right. If the proxy finds that the new observation request from the client is (almost) identical to the previous observation request from the client, then this behavior is exactly the one intended. The proxy could also try to do it when the requests are not identical, but this would violate the "MUST be identical" client requirement, although it might technically work due to the "MUST replace or update the existing" server requirement. I wouldn't assume that any proxy does it in this case. At first glance, I don't see any. Klaus