Original text:
Every time a client issues a new Observe request, a new Partial IV MUST be used (see cose-object), and so the payload and OSCORE option are changed.  The server uses the Partial IV of the new request as <del> the 'request_piv' of all associated notifications (see AAD).  The Partial IV of the registration is also used as 'request_piv' of associated cancellations (see AAD). </del>  Intermediaries are not assumed to have access to the OSCORE security context used by the endpoints, and thus cannot make requests or

Reviewer comments:
Solves issue (from review comments by NAME : URL)
In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field.
Another case to make sure that works Client - please cancel my observation Server - I don't have an observation for you, but sure I am willing to tell you I canceled it. What request PIV would I use in the AAD?
Yes, the verification of cancellation would fail since the server does not have the initial registration's partial iv saved, if it does not have the observation stored. So OSCORE would fail, which is not right. We have reverted to previous version (request_piv is not exception for cancellations) in c94314321 , but we want to add some security considerations about Observe and cancellations before closing this issue. Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.

Revised text:
Every time a client issues a new Observe request, a new Partial IV MUST be used (see cose-object), and so the payload and OSCORE option are changed.  The server uses the Partial IV of the new request as  <ins> the 'request_piv' of all associated notifications (see AAD). </ins> Intermediaries are not assumed to have access to the OSCORE security context used by the endpoints, and thus cannot make requests or