Definitely the text should be correct! :)
We can't suggest using TCP keepalives as an alternative of app layer
keepalives without breaking interop. But I will make another pass at the
document later today to try to address the other points we've discussed.
The discussion about the TCP
Hi Ted,
see inline.
> Am 26.10.2018 um 16:58 schrieb Ted Lemon :
>
> Okay, I'm going to update the document to add a clarification about the
> handling of early data outside of TFO. I think the keepalive issue is a
> matter of judgment, and we would almost have to rewrite the document to
>
Okay, I'm going to update the document to add a clarification about the
handling of early data outside of TFO. I think the keepalive issue is a
matter of judgment, and we would almost have to rewrite the document to
change how that works now. Looking at the MacOS documentation, I can see
ways
Hi Ted,
please see below.
> Am 26.10.2018 um 15:59 schrieb Ted Lemon :
>
> On Fri, Oct 26, 2018 at 9:35 AM Mirja Kuehlewind (IETF)
> wrote:
> I guess you mean RFC8446 :-)
> Yup, sorry.
>
> The table there on p.18 shows only the TLS handshake, there is a TCP
> handshake before that.
>
> I
On Fri, Oct 26, 2018 at 9:35 AM Mirja Kuehlewind (IETF)
wrote:
> I guess you mean RFC8446 :-)
>
Yup, sorry.
> The table there on p.18 shows only the TLS handshake, there is a TCP
> handshake before that.
>
I don't believe this is correct, and given your comment at the end maybe
I'm just
Hi Ted,
please see below.
> Am 23.10.2018 um 21:51 schrieb Ted Lemon :
>
> On Mon, Oct 15, 2018 at 10:02 AM Mirja Kuehlewind (IETF)
> wrote:
> sorry for the delay, however, as you performed a couple of changes it took me
> a while to re-review. I believe I’m unfortunately not fully ready to
On Mon, Oct 15, 2018 at 10:02 AM Mirja Kuehlewind (IETF) <
i...@kuehlewind.net> wrote:
> sorry for the delay, however, as you performed a couple of changes it took
> me a while to re-review. I believe I’m unfortunately not fully ready to
> release my discuss at this point, but close..
>
No
On Mon, Oct 15, 2018 at 04:56:18PM +0200, Mirja Kuehlewind (IETF) wrote:
> Sorry, one more comment on section 11.1:
> "DSO permits zero round-trip operation using TCP Fast Open [RFC7413]
> with TLS 1.3 [RFC8446] 0-RTT to reduce or eliminate round trips in
> session establishment.“
>
> This
Sorry, one more comment on section 11.1:
"DSO permits zero round-trip operation using TCP Fast Open [RFC7413]
with TLS 1.3 [RFC8446] 0-RTT to reduce or eliminate round trips in
session establishment.“
This sounds like TCP Fast Open and TLS 0-RTT can only be used together. However
these
Hi Ted,
sorry for the delay, however, as you performed a couple of changes it took me a
while to re-review. I believe I’m unfortunately not fully ready to release my
discuss at this point, but close..
Regarding my first discuss point (delayed ACKs aso.) I think the text improved
and I would
One minor comment (as I’m reviewing the updated version…)
> Am 02.08.2018 um 08:35 schrieb Ted Lemon :
>
> 4) sec 5.1 "It is a common
>convention that protocols specified to run over TLS are given IANA
>service type names ending in "-tls"."
> Not sure this is true. Isn't it usually just
On Wed, Oct 10, 2018 at 5:15 AM "Mirja Kühlewind (IETF)" <
i...@kuehlewind.net> wrote:
> Hi Warren, hi Ted,
>
> sorry I was on holidays a couple of days last week and am completely
> behind everything. Will try to have a look as soon as possible. Maybe
> Friday or next week…
>
Ok, thank you.
Not
Hi Warren, hi Ted,
sorry I was on holidays a couple of days last week and am completely behind
everything. Will try to have a look as soon as possible. Maybe Friday or next
week…
Mirja
> Am 09.10.2018 um 16:51 schrieb Warren Kumari :
>
> Mirja -- checking in again.
>
> W
>
> On Tue, Oct
Mirja -- checking in again.
W
On Tue, Oct 2, 2018 at 1:08 PM Warren Kumari wrote:
> Mirja, just checking in.
>
> The most recent version satisfied Benjamin, and I *think* it satisfies
> your comment too.
>
> W
>
> On Thu, Sep 27, 2018 at 12:57 AM Ted Lemon wrote:
>
>> Mirja, I notice that you
Mirja, just checking in.
The most recent version satisfied Benjamin, and I *think* it satisfies your
comment too.
W
On Thu, Sep 27, 2018 at 12:57 AM Ted Lemon wrote:
> Mirja, I notice that you are still holding a discuss on this document. I
> believe that we addressed the concerns you
Mirja, I notice that you are still holding a discuss on this document. I
believe that we addressed the concerns you raised in your discuss. Could you
please let us know if there is still work to do on this, and if not, clear the
discuss?
Thanks!
On Mon, Jul 30, 2018 at 4:19 PM, Mirja Kühlewind
wrote:
[Skipping the DISCUSS, which I hope we have already addressed.]
1) sec 3: I really find it a bit strange that there is normative language
> about
> error handling (as well as in the "same service instance" definition part)
> in
> the
On Wed, Aug 1, 2018 at 8:02 AM, Mirja Kuehlewind (IETF) wrote:
> >> 1) In addition to the bullet point in the 6.2 that was flagged by
> Spencer, I
> >> would like to discuss the content of section 5.4. (DSO Response
> Generation). I
> >> understand the desire to optimize for the case where the
Hi Stuart,
please see below.
> Am 01.08.2018 um 09:48 schrieb Stuart Cheshire :
>
> On 30 Jul 2018, at 13:19, Mirja Kühlewind wrote:
>
>> --
>> DISCUSS:
>>
On 30 Jul 2018, at 13:19, Mirja Kühlewind wrote:
> --
> DISCUSS:
> --
I’m responding to the “DISCUSS” items right now. I’ll get to the “COMMENT”
items
Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnsop-session-signal-12: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
21 matches
Mail list logo
