[core] Review draft-amsuess-core-cachable-oscore-00

[Jim Schaad <[e-mail]>]

I will admit that I found what was proposed here to be very interesting.  I
am unsure of how well it would work and think that we may want to workshop
it at some point just to figure that out.

*  Reading this document made me really long for an OSCORE padding document
where the message can be predictably padded out to fixed length so that it
would make one of the issues raised in this document moot.

* One place where this could also be useful is where a large number of
entities are going to fetch the same object on a reasonably frequent basis
and it does not matter if external parties can determine if they are all
asking for the same thing.  The server could then always update the ETAG and
generate a new response, padded, whenever it either changes or it has aged
out.

* One wonders about the goodness of returning both a "This is what the
deterministic request says and here is the encoded request but you cannot
decrypt it".  It does mean that you need to have a degree of trust for the
server not lying to you but would potentially allow for an even shorter
request.

* It might be worthwhile to signal that you are going to ask a lot and use
an application/multiple-coap content to return both the answer and the
deterministic request.  This means that it would not be cached until the
next ask but that is going to be true anyway if the server is providing this
request.

Jim