Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stun-dtls-05
Yes
(Alissa Cooper)
(Spencer Dawkins)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Barry Leiba)
(Brian Haberman)
(Joel Jaeggli)
(Pete Resnick)
(Ted Lemon)
Note: This ballot was opened for revision 04 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(for -04)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(for -04)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -04)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2014-06-24 for -04)
Unknown
First of all, let me applause. I don't recall the last time a WG was ahead of schedule. Jul 2014 Send draft adding DTLS as a transport for STUN/TURN to IESG for publication as Proposed Standard draft-ietf-tram-stun-dtls Confused by the abstract/footer. The former is "DTLS for STUN", while the latter is "TURN over DTLS". Both should be aligned. Wouldn't the abstract/footer be more accurate with "DTLS for STUN and TURN" or maybe "DTLS for ICE"?
Brian Haberman Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2014-06-25 for -04)
Unknown
Editorial: Section 4.3 has some broken XML code for the reference.
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-06-24 for -04)
Unknown
Thank you for addressing the SecDir review comments. I'll look for the update as many good points were made and discussed with the editors. This is a placeholder to watch for the corrections identified in the review. The discussion looks good so far, thanks. Could a reference be added for the two items in this description of the Introduction? This sub-optimality primarily stems from the added latency incurred by the TCP-based head-of-line (HOL) blocking problem coupled with additional TLS buffering (for integrity checks).
Martin Stiemerling Former IESG member
(was Discuss)
No Objection
No Objection
(2014-06-27)
Unknown
thank you for addressing the discuss.
Pete Resnick Former IESG member
No Objection
No Objection
(for -04)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-06-26 for -04)
Unknown
- section 3, last para: the magic cookie is mentioned here without introduction. Maybe add a ref to section 6 of 5389 if that's the right place? - 4.1.1: "The <host> value MUST be used when using the rules in Section 7.2.2 of [RFC5389] to verify the server identity. A STUN URI containing an IP address MUST be rejected, unless the domain is provided by the same mechanism that provided the STUN URI, and that this domain name can be passed to the verification code." I didn't get that sorry, can you explain what it means? The "domain is provided by" bit confused me. (Same for end of 4.6.1) - 4.2, 1st para: "not possible" hmm. Well, if the same SDP stuff is sent to many places then it is, or if the attacker can otherwise see the SDP stuff. Isn't that common or won't it be common with WebRTC? - 4.2, 2nd para: I'm not getting if you're encouraging folks to use [I-D.thomson-rtcweb-ice-dtls] or not. Might help to be clear about that. (I've not followed the discussion on that draft though.) - Section 5: Thanks!
Ted Lemon Former IESG member
No Objection
No Objection
(for -04)
Unknown