Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)
RFC 7350

Note: This ballot was opened for revision 04 and is now closed.

Alissa Cooper Yes

(Spencer Dawkins) Yes

(Jari Arkko) No Objection

Comment (2014-06-25 for -04)
No email
send info
Editorial: Section 4.3 has some broken XML code for the reference.

(Alia Atlas) No Objection

(Benoît Claise) No Objection

Comment (2014-06-24 for -04)
No email
send info
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"?

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-06-26 for -04)
No email
send info
- 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!

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-06-24 for -04)
No email
send info
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).

(Pete Resnick) No Objection

(Martin Stiemerling) (was Discuss) No Objection

Comment (2014-06-27)
No email
send info
thank you for addressing the discuss.