Change:
OSCORE payload is defined for potential future use cases and SHALL NOT be used in the OSCORE message.  The OSCORE payload cannot be understood without the OSCORE option value and the security context. <ins> 13.7. It is requested that IANA create a new registry entitled "OSCORE Octet".  The registry should be created with the Expert Review policy.  Guidelines for the experts are provided in exp-instr. The columns of the registry are: bit position: This indicates the position of the bit in the OSCORE Octet, starting at 0 for the most significant bit.  The bit position must be an integer or a range of integers, in the range 0 to 63. name: The name is present to make it easier to refer to and discuss the registration entry.  The value is not used in the protocol.  Names are to be unique in the table. description: This contains a brief description of the use of the bit. specification: This contains a pointer to the specification defining the entry. The initial contents of the registry can be found in _table-flagbyte. The specification column for all rows in that table should be this document.  Additionally, the entry with Bit Position of 0 is to be marked as 'Reserved'.  This entry is going to be specified in a future document, and will be used to expand the OSCORE Octet in obj- sec-value, so that entries 8-63 of the registry are defined. 13.8. The expert reviewers for the registry defined in this document are expected to ensure that the usage solves a valid use case that could hardly be solved in a different way, that it is not going to duplicate one that is already registered, and that the registered point is likely to be used in deployments.  They are furthermore expected to check the clarity of purpose and use of the requested code points.  Experts should take into account the expected usage of entries when approving point assignment, and the length of the encoded value should be weighed against the number of code points left that encode to that size and the size of device it will be used on.  Experts should block registration for entries 8-63 until these points are defined (i.e. until the mechanism for the OSCORE Octet expansion via bit 0 is specified). </ins>

Discussion:
Solves issue (from review comments by NAME : URL) 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.