Subject: [TLS] Draft minutes for IETF-75 available

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 3 Aug 2009 11:28:56 -0700

Draft minutes for IETF 75 are available here:

http://www.ietf.org/proceedings/75/minutes/tls.txt

Let me know if you have corrections.

Thanks,

Joe

---

From: "tom.petch" <[email-masked]>
Date: Thu, 6 Aug 2009 09:30:46 +0200

I see that the TLS heartbeat extension is mentioned in the minutes.

Discussion of this on the syslog and IPFIX lists said
"However, it's not clear if the TLS WG will support the draft."

I would like to see it supported.

Tom Petch

----- Original Message -----
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 03, 2009 8:28 PM

> Draft minutes for IETF 75 are available:
>
> Transport Layer Security (TLS) Working Group Minutes
> Meeting : IETF75, July 31, 2009
> Location: Stockholm, Sweden, Room 307, 1300-1400
> Chairs  : Joseph Salowey <[email-masked]>,
> Eric Rescorla <[email-masked]>
> Minutes : Wes Hardaker, Jeff Hodges
> Version 2
>
>
> 3. DTLS Heartbeat - Presented by Michael Tuexen
>
> Draft:
http://www.ietf.org/internet-drafts/draft-seggelmann-tls-dtls-heartbeat-00.txt
>
> Pasi Eronen (AD): I can see this being useful in cases, but I can also see
>       it being solved in the lower layer protocols.  For example, in IPFIX I
>       can very much see them solving it at their layer.
> Michael Tuexen: I see your point but...
> Pasi: I can also see this useful for PMTU discovery.
> Michael: That's true but it doesn't necessarily work for bi-directional
> differences.  You can send another message which contains extra
> stuff for doing discovery.  SCTP has opaque data for doing
> things like that.  I like the discovery message, but I think
> it should be another message.
> Eric (Jabber): this is relevant in TCP cases as well.
>
> Question: if you use this in UDP, the draft says you must not send them
>       while you're waiting for a response.
> Michael: Only one heart-beat request in flight at a time.  I don't want
> to have a congestion control problem
>
> Wes Hardaker: agree with EKR that it is useful it TCP as well,
>       though you need to document differences.  Longer discussion on
>       the rational behind it.