Re: [Lake] [core] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06

[Christian Amsüss <[e-mail]>]

Hello Marco,

thanks for the update.

I have one note, but that's more on the general
how-do-we-describe-CoAP-processing and likely not actionable in this
document:

On Tue, Mar 14, 2023 at 02:33:23PM +0100, Marco Tiloca wrote:
> > * 3.2.1 item A is quite a mouth-ful to say that "On Inner Block-wise,
> >    3.2 only applies to the first block", but I see that given how the
> >    rest is phrased, it is unavoidable.
> > 
> >    Maybe using the term "first application CoAP request" suggested above
> >    opens an avenue for making this easier to comprehend.
> 
> ==>MT
> Yes, we have rephrased as you suggest.
> <==

I still think we should manage to do better when layering documents,
so that sections like this would not be phrased in conditional form any
more -- but this is probably as good as things get here without
rewriting more of the ecosystem.

(On the long run, I'd hope we'll find the right terminology to express
that the application builds a request, then it gets passed into a
fragmenter, then gets OSCORE encrypted, then gets EDHOC things added,
then gets passed into an outer fragmenter, then passed to a transport,
and that each of these steps is quite independent from the others
while still providing details such as a reduced MTU size -- but so far
we can't even do that in APIs, and I dare say it's more complicated to
do it cleanly in specifications that also need to be true to
implementations that do roll some of these steps into one software
component).

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom