Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block

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

Hello Jon,
and hello Michael (grep for MCR, first point could use your response),

thanks for your responses and updates; on these concrete points, the
only that remain are:

> > * "If there is insufficient space to create a response PDU": I don't
> >   understand what that means. (Where are request options reflected
> >   back?).
> 
> [Jon] This was triggered by a question by Michael Richardson " So, given a
> Christmas-Tree-Packet (largest packet, every possible option space used,
> every extension turned on...) how much data can I get back? :-)" and not
> fully thought through.
> It could happen though with Location-Path, Location-Query, Q-Block2, ETag,
> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE  in response to
> a POST.
> OLD
>    If there is insufficient space to create a response PDU with a block
>    size of 16 bytes (SZX = 0) to reflect back all the request options as
>    appropriate, a 4.13 (Request Entity Too Large) is returned without
>    the Size2 Option.
> NEW
>    If there is insufficient space to create a response PDU with a block
>    size of 16 bytes (SZX = 0) to send back all the response options as
>    appropriate, a 4.13 (Request Entity Too Large) is returned without
>    the Size1 Option.

I think that is a corner case that deserves an error in *every* CoAP
based protocol and is not specific to it; MCR do you think that this
comment needs to be resolved in this way?

> > * "For NON transmissions": This seems to imply that the full exchange of
> >   a body is either NON or CON; I don't see where that'd come from. I'd
> >   have expected to read something like "Each individual request can be
> >   NON or CON independent of the others. In particular, it can be
> >   convenient to send the ultimate payload...".
> 
> [Jon]The DOTS environment will only be using NON.  To make Congestion
> Control simple,
> the expectation is that all transmissions are NON or (not recommended) are
> all CON. The draft now generally records this expectation.

Then why spend time talking about CON in the first place, and risk that
things go awry in a case that's neither tested nor really specified for?

It may be worth considering (ie. working group discussion; next interim
maybe?) to just state that this works with NON only.

I do see potential for the use of CON and NON mixed (in particular, the
"but it doesn't have a dual version for server pushes" you dread of
No-Response problem might go away), but if it's not explored to fruition
in the problem set out for this document, confirmable messages may be
better ruled out at all rather than getting second-class treatment.

> > Caching:
> > 
> > * "are not part of the cache key": How about "are removed as part of the
> >   block assembly and thus do not reach the cache"?
> 
> [Jon] OK.
> OLD
>    As the entire body is being cached in the proxy, the Q-Block1 and
>    Q-Block2 Options are not part of the cache key.
> NEW
>    As the entire body is being cached in the proxy, the Q-Block1 and
>    Q-Block2 Options are removed as part of the
> block assembly and thus do not reach the cache.

It may help to make the same statement about Request-Tag; then, there is
no more (IMO questionable) SHOULD about "a new Request-Tag [being]
generated", and the "Ideally" sentence can be dropped too.

> >     Generally, the all-NON and all-CON examples don't look to me like
> >     what I'd be doing with this spec; the mixed "a CON every
> >     MAX_PAYLOADS" appears much more realistic.
> 
> [Jon] It is unsafe to use CON in the  (potentially lossy) DOTS environment
> (up to 93 secs timeout per payload with the defaults).  Hence why we are
> separating out the NON / CON usage.

See above: then maybe don't do it at all.

(Also, in the "not related to previous points" follow-up mail to come,
there are some CON related questions that might be moot then).


Best regards
Christian

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