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

From: Carsten Bormann <[email-masked]>
Date: Wed, 06 Apr 2016 14:45:25 -0300

As discussed in a previous message, the in-room consensus in Buenos
Aires was to revert the decision we made in Yokohama to go for
alternative L1, and to instead select alternative L3.

This is a one-week call for confirmation of that decision.
Specifically, if you have an objection to this decision, please speak up
on the mailing list by 2016-04-13.

Grüße, Carsten

---

From: Simon Lemay <[email-masked]>
Date: Wed, 13 Apr 2016 23:29:56 +0000

Hi all,

Sorry for missing the meeting, but I had a few questions concerning the
decision, not that I am not necessarily oppose to the change, but I does
come as a surprise.

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.

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)

Cheers

Simon

On Wed, Apr 6, 2016 at 10:45 AM Carsten Bormann <[email-masked]> wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Apr 2016 03:01:04 +0200

Hi Simon,

good to hear from you -- this is exactly why we validate in-room
decisions on the mailing list.

> head-of-line blocking, should we still consider bert draft that was

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

---

From: Simon Lemay <[email-masked]>
Date: Sun, 17 Apr 2016 14:49:53 +0000

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Apr 2016 12:21:20 +0100

> on the mailing list by 2016-04-13.

As Carsten is listed one of the editors and he currently has no
co-chair, he asked me to officially close this confirmation call.

I've heard no objections to this change.

Best Regards,
Alexey,
Responsible ART AD for the CORE WG