Draft: draft-ietf-core-object-security

Commentary: Solves issue ( from review comments by : ) 
 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 do n't plan to set an outer    option . 
 Closed in
Mailing list commentary: 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 do n't plan to set an outer 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 i d.
Paragraph (version A):
An Outer Max-Age message field is used to avoid unnecessary caching
of OSCORE error responses at OSCORE-unaware intermediary nodes.  A
server MAY set a Class U Max-Age message field with value zero to
OSCORE error responses, which are described in Sections replay-
protection, ver-req, and ver-res.  Such a message field is then
processed according to outer-options.
Paragraph (version A):
Successful OSCORE responses do not need to include an Outer Max-Age
option since the responses are non-cacheable by construction (see
coap-header).
Paragraph (version B):
An Outer Max-Age message field is used to avoid unnecessary caching
of error responses caused by OSCORE processing at OSCORE-unaware
intermediary nodes.  A server MAY set a Class U Max-Age message field
with value zero to such error responses, described in Sections
replay-protection, ver-req, and ver-res, since these error responses
are cacheable, but subsequent OSCORE requests would never create a
hit in the intermediary caching it.  Setting the Outer Max-Age to
zero relieves the intermediary from uselessly caching responses.
Successful OSCORE responses do not need to include an Outer Max-Age
option since the responses appear to the OSCORE-unaware intermediary
as 2.04 Changed responses, which are non-cacheable (see coap-header).
Paragraph (version B):
The Outer Max-Age message field is processed according to outer-
options.