Agreed on all counts.
RFC Editor, this phrase appears twice in Section 1.1 -- do you know if the
inline errata tooling will do something useful with the Original/Corrected
text as currently shown, or should I extract a larger snippet so that both
instances can be done together?
Thanks,
Ben
On
Hi Folks,
We had a presentation on TLS opaque at IETF 110, but we have not had much
discussion of this document on the list. The chairs would like to see more
discussion on the document before considering it for adoption. There is at
least one question on the list that has gone unanswered for
On 3/30/21 at 2:47 PM, martin.h.d...@gmail.com (Martin Duke) wrote:
To reiterate, I believe introducing latency regressions with respect to
DTLS 1.2 would be bad for the internet. So what's new in the area under
discussion is (a) lowering the timeout from 1s to 100ms, and (b) the
introduction
Hi Hannes,
Yes, I understand that the scope of this is limited to the handshake, plus
the occasional post-handshake message. That's one reason I'm willing to
entertain significant deviations from the BCPs on this subject.
On Tue, Mar 30, 2021 at 12:24 PM Hannes Tschofenig <
> The strawman in my DISCUSS was that bursts of <= 2 packets could
> be more aggressive; that's a negotiable number, and the de jure
> TCP 4*MSS initial window, for example, is one I can easily be
> persuaded of.
Well.
On the standards track you're correct (RFC 3390 & 5681).
However, RFC 6928
Hi Martin,
the main issue Ekr is bringing up is that the DTLS handshake happens
infrequently and it is small in size.
The use of DTLS for protecting application traffic is not impacted by this
timeout.
Ciao
Hannes
-Original Message-
From: Martin Duke
Sent: Tuesday, March 30, 2021
Thank you Eric (and Mark).
To reiterate, I believe introducing latency regressions with respect to
DTLS 1.2 would be bad for the internet. So what's new in the area under
discussion is (a) lowering the timeout from 1s to 100ms, and (b) the
introduction of ACKs.
I would characterize ekr's reply
