Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt

From: Sean Turner <[email-masked]>
Date: Wed, 09 Mar 2011 15:55:56 -0500

On 2/1/11 3:20 PM, Michael Tüxen wrote:
> On Feb 1, 2011, at 3:31 PM, Sean Turner wrote:
>
>> On 2/1/11 4:23 AM, t.petch wrote:
>>> ----- Original Message -----
>>> From: "Michael Tüxen"<[email-masked]>
>>> To: "Florian Weimer"<[email-masked]>
>>> Cc:<[email-masked]>
>>> Sent: Thursday, January 27, 2011 2:49 PM
>>>
>>> On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote:
>>>
>>>>> This document describes the Heartbeat Extension for the Transport
>>>>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
>>>>> protocol.
>>>>
>>>> I think this paragraph
>>>>
>>>> | There MUST NOT be more than one HeartbeatRequest message in flight
>>>> | at a time.
>>>>
>>>> should be changed to:
>>>>
>>>> | Retransmissions MUST use the same payload as the original
>>>> | HeartbeatRequest message.
>>> The intention of the sentence in the ID is that you can not send
>>> multiple HeartbeatRequest out. This could overload the network since
>>> DTLS uses transport layers which do not necessary provide a congestion
>>> control. That is why you can only have one request in flight.
>>> Please note that it is not in flight anymore if the corresponding
>>> HeartbeatReply has been received or the retransmission timer fires.
>>>
>>> Michael
>>>
>>> My experience of the IESG is that they will insist on a paragraph about
>>> Congestion Control (lack of) and mitigation thereof.  At the same time,
>>> I find it very hard to know what words will satisfy them; my most recent
>>> experience was with RFC6012, albeit a more complex scenario.
>>>
>>> Tom Petch
>>
>> I suspect that the transport ADs' interest will be piqued the minute they read the words: mtu ;)  The best thing to do is to ask for an early review from [email-masked].  I'm willing to send it over if you'd like?
> Hi Sean,
>
> yes, please send it over to them.
>
> Robin and myself are working on some minor text changes and it would be
> nice to address also the comments we get from the tsv-dir in the next
> revision.
>>
>> This is my bad, because I haven't yet figured out what magic incantation needs to go in drafts to appease the transport (and probably internet area) ADs.
> Hmm. Regarding path MTU discovery we made references to RFC 4821, which
> should make them happy (I hope).
>
> But let us get their comments and improve the document.
>
> Best regards
> Michael
>>
>> spt
>>

No word from tsv-dir.  I re-pinged the list moderators and ADs.

spt