Skip to main content

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