Subject: Re: [core] Mirja Kühlewind's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS)

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 28 Jul 2017 13:38:00 +0200

Hi Carsten,

I checked the latest version of the draft and I don’t really see my other discuss points addressed (points 2 and 3 mainly about connection handling and timing). Can you please explain how this is addressed? 

Related to some previous comments you provided: some of these points might be addressed by an application on top of coap, however, this draft should a) indicate that the application has to care about it, b) provide recommendation what to do under which considerations, and c) potentially even provide default parameters where possible.

Thanks,
Mirja

> Am 10.05.2017 um 21:05 schrieb Carsten Bormann <[email-masked]>:
> 
> On May 10, 2017, at 18:49, Mirja Kühlewind <[email-masked]> wrote:
>> 
>> You cannot use TCP without it reliability features. Having additional reliability in the higher layer simply means the reliability is not used.
> 
> … or that the features are suddenly viewed as conveying application (or even end-to-end) reliability.
> Much safer to remove them.
> 
> Grüße, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Jul 2017 14:36:59 +0200

Hi Mirja,

thank you for looking at the document again, and for clarifying that you do expect some changes in the text and not just the email comments we made.

Just to gauge the level of detail you expect here:  One plan would be to appropriate some text from section 6 of RFC 7230, which might include phrases such as "It is beyond the scope of this specification to describe “ and "Implementations ought to anticipate the need to recover from asynchronous close events.”  

I don’t think it is the intention of the WG to prescribe specific timing or other parameters related to connection management; e.g., we have learned from RFC 2616 that standardizing a specific number for the limit to simultaneous connections (end of section 8.1.4 there) can be a mistake; this was not repeated in RFC 7230 (replacement text: "A client ought to limit the number of simultaneous open connections that it maintains to a given server.” — no specific number given, and non-RFC2119 “ought to” language).

I expect we will have text for this in the next version -10 shortly.

Grüße, Carsten

> On Jul 28, 2017, at 13:38, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Carsten,
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 28 Jul 2017 15:15:41 +0200

Hi Carsten again,

thanks! Actually my discuss point 3 is not an application requirement but a protocol mechanism and in this case at least recommended numbers make sense, where a number can depend on e.g. the RTT.

Will wait for the update!

Mirja

> Am 28.07.2017 um 14:36 schrieb Carsten Bormann <[email-masked]>:
> 
> Hi Mirja,
>