Original text:
forwarding by intermediary nodes. The server SHALL include a new Partial IV in responses (with or <del> without the Observe option) to Observe registrations. </del>  RFC7252 does not specify how the server should act upon receiving the same Token in different requests.  When using OSCORE, the server 4.1.3.5.2. If the server accepts an Observe registration, a Partial IV MUST be <del> included in all notifications (both successful and error).  To protect against replay, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the received notifications for the associated Observe registration. Further details of replay protection of notifications are specified in replay-notifications. </del>  For notifications, the Inner Observe value MUST be empty (see Section 3.2 of RFC7252).  The Outer Observe in a notification is as the freshest, regardless of the order of arrival.  In order to support existing Observe implementations the OSCORE client implementation MAY set the Observe value to the three least <del> significant bytes of the Partial IV. </del>  4.1.3.6. The Notification Number is initialized to the Partial IV of the first successfully verified notification in response to the registration <del> request.  A client receiving a notification SHALL compare the Partial IV with the Notification Number associated to that Observe registration.  The client MUST stop processing notifications with a Partial IV which has been previously received.  Applications MAY decide that a client only processes notifications which have greater Partial IV than the Notification Number. </del>  If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number then the client If Observe is supported, insert the following step between step 2 and 3 of prot-res: <del> A.  If the request was a registration, encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one.  Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV, then go to 4. </del>  8.4. A.  If the request was an Observe registration, then: <del> If the Partial IV is not present in the response, and either the client has previously received a successful notification to the registration (active observation) or Inner Observe is present, then go to 8. </del>  If the Partial IV is present in the response and Inner Observe is present, then follow the processing described in notifications and

Reviewer comments:
Solves issue (from review comments by NAME : URL)
According to Jim, the change of always including a Partial IV for notifications (both successful or errors) complicates the code too much, although it simplifies the spec, so he proposes to revert that change. 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:
forwarding by intermediary nodes. The server SHALL include a new Partial IV in responses (with or  <ins> without the Observe option) to Observe registrations, except for the first response where Partial IV MAY be omitted. </ins> RFC7252 does not specify how the server should act upon receiving the same Token in different requests.  When using OSCORE, the server 4.1.3.5.2. If the server accepts an Observe registration, a Partial IV MUST be  <ins> included in all notifications (both successful and error), except for the first one where Partial IV MAY be omitted.  To protect against replay, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the received notifications for the associated Observe registration.  Further details of replay protection of notifications are specified in replay-notifications. </ins> For notifications, the Inner Observe value MUST be empty (see Section 3.2 of RFC7252).  The Outer Observe in a notification is as the freshest, regardless of the order of arrival.  In order to support existing Observe implementations the OSCORE client implementation MAY set the Observe value to the three least  <ins> significant bytes of the Partial IV; such an implementation needs to make sure that the Observe value for an observe notification without Partial IV is smaller than a notification with Partial IV. </ins> 4.1.3.6. The Notification Number is initialized to the Partial IV of the first successfully verified notification in response to the registration  <ins> request.  A client MUST only accept at most one Observe notifications without Partial IV, and treat it as the oldest notification received. A client receiving a notification containing a Partial IV SHALL compare the Partial IV with the Notification Number associated to that Observe registration.  The client MUST stop processing notifications with a Partial IV which has been previously received. Applications MAY decide that a client only processes notifications which have greater Partial IV than the Notification Number. </ins> If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number then the client If Observe is supported, insert the following step between step 2 and 3 of prot-res:  <ins> A.  If the response is an observe notification: If the response is the first notification: compute the AEAD nonce as described in nonce: Either use the nonce from the request, or Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV. Then go to 4. If the response is not the first notification: encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV, then go to 4. </ins> 8.4. A.  If the request was an Observe registration, then:  <ins> If the Partial IV is not present in the response, and Inner Observe is present, and the nonce from the request was already used once, then go to 8. </ins> If the Partial IV is present in the response and Inner Observe is present, then follow the processing described in notifications and