The PR looks good to me.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Can we modify the existing draft to say 0-200 tickets not 0-255?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Dear Christopher Wood,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
tls Session 1 (1:00 requested)
Monday, 23 March 2020, Afternoon Session III 1810-1910
Room Name: Plaza B/C size: 300
--
Hi!
Based on Tommy Pauly’s suggestion [0], Joe and I believe that the best way for
us to get to the place where we can declare rough consensus is to:
* Consider the PR: [1]. This PR explains that when racing connections, the
client will not necessarily know the number of tickets it will “consu
On Fri, Feb 28, 2020 at 10:58 AM Jonathan Hoyland <
jonathan.hoyl...@gmail.com> wrote:
> On Fri, 28 Feb 2020 at 04:49, Christopher Wood
> wrote:
>
>> On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
>> > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland
>> > wrote:
>> > > This would be for
On Fri, Feb 28, 2020, at 7:58 AM, Jonathan Hoyland wrote:
>
>
> On Fri, 28 Feb 2020 at 04:49, Christopher Wood wrote:
> >
> >
> > On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
> > > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland
> > > wrote:
> > > > This would be for cases
On Fri, 28 Feb 2020 at 04:49, Christopher Wood wrote:
>
>
> On Thu, Feb 27, 2020, at 1:31 PM, David Benjamin wrote:
> > On Mon, Feb 24, 2020 at 5:58 PM Jonathan Hoyland
> > wrote:
> > > This would be for cases where we want to inject extra context into a
> resumption.
> > > That would be anythin
Hanno,
Thanks for your note. I don't think your proposal will be an
improvement. It destroys information which could otherwise be used for
improve round-trip and loss estimation (cf. the difference between
QUIC and TCP ACKs). Second, it prevents the receiver from saying
some non-sensical things li
Hi,
TL;DR
This is all about various aspects of how ACKs work in DTLS 1.3:
- The DTLS 1.3 specification requires clarification regarding
when ACKs should be sent.
- Record-level ACKs make efficient implementations for IoT
devices harder. I argue that handshake-level ACKs reduce
implementation
