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

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"<Michael.Tuexen@lurchi.franken.de>
>> To: "Florian Weimer"<fweimer@bfk.de>
>> Cc:<tls@ietf.org>
>> 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 tsv-dir@ietf.org.  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
> 
>>> 
>>> The original requirement seems to be pretty much unimplementable
>>> because of transport layer characteristics.
>> Not sure what problem you are thinking about.
>> An implementation of the ID for OpenSSL is available at
>> http://sctp.fh-muenster.de/dtls-patches.html
>> 
>> Best regards
>> Michael
>>> 
>>> --
>>> Florian Weimer<fweimer@bfk.de>
>>> BFK edv-consulting GmbH       http://www.bfk.de/
>>> Kriegsstraße 100              tel: +49-721-96201-1
>>> D-76133 Karlsruhe             fax: +49-721-96201-99
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> 