Re: [core] 🔔 Confirmation call: CoAP over TCP/TLS #396: Revert L1 selection, select L3

[Simon Lemay <[e-mail]>]

Hi Carsten,

Thanks for the answer,

When I said L3 I guess I implied larger payload, but yes this makes sense.
And I do believe that we should keep working on BERT.

I also think we should have something in place so constraint device can
refuse a message if too large

But yes this make sense, thanks for the explanation.

Simon


On Wed, Apr 13, 2016 at 18:01 Carsten Bormann <[e-mail]> wrote:

> Hi Simon,
>
> good to hear from you -- this is exactly why we validate in-room
> decisions on the mailing list.
>
> > I know one of the main concern of L3 in the pass was the possibility of
> > head-of-line blocking, should we still consider bert draft that was
> > proposed.
>
> That is not a concern with L3, but a concern with large messages.
> Yes, these do exhibit head-of-line blocking.
> BERT is a good way to control the extent of this blocking, so I think
> this is still a useful extension to pursue.
>
> > The other concern was on how smaller device fit in this, if you send
> > large payload that are out of scope for a constraint device, how should
> > this be handle (if should be handle that the procol level)
>
> As we said, there is no intention to revoke the SHOULDs in section 4.6
> of RFC 7252.  However, there is also no intention to enforce these
> SHOULDs (policy) by providing an artificial limitation to the message
> size (mechanism) at the encapsulation level.
>
> L3 does not prevent you from shooting yourself in the foot by ignoring
> section 4.6 (note that L2 didn't really do that, either, 64 KiB is still
> larger than 1152).  But L3 also doesn't stop you from transcending 4.6
> significantly if you have a good reason to do so.
>
> Grüße, Carsten
>