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; former steering group member) Yes

Yes ( for -04)
No email
send info

(Spencer Dawkins; former steering group member) Yes

Yes ( for -04)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection (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"?

(Brian Haberman; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Jari Arkko; former steering group member) No Objection

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

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (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).

(Martin Stiemerling; former steering group member) (was Discuss) No Objection

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

(Pete Resnick; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (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!

(Ted Lemon; former steering group member) No Objection

No Objection ( for -04)
No email
send info