TCP Candidates with Interactive Connectivity Establishment (ICE)
RFC 6544
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
(David Harrington; former steering group member) Yes
(Gonzalo Camarillo; former steering group member) Yes
(Robert Sparks; former steering group member) Yes
Are you sure we can't get consent to publish this without the pre5378 boilerplate? On page 17, the sentence "STUN is never run within the TLS or DTLS-SRTP session." is too strong. STUN may not occur within those sessions because of ICE, but some application that's using that candidate later may have a reason to run STUN there. I suggest adding "as part of the ICE procedures" to the end of that sentence.
(Wesley Eddy; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
Section 1 However, ICE only defines procedures for UDP-based transport protocols. I think "UDP-based transport protocols" is wrong snce UDP *is* a transport protocol. 5245 talks about "UDP-based media streams" and "UDP".
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
Thank you fow writing this document. It is a complex topic but the document was quite easy to read.
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) No Objection
I support Stephen's discuss.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- on page 3, 2nd last para where it talks about "one of the agents" it might be clearer to say "one of the agents (the offerer)" - lack of ICE-clue means I didn't get the last para of p5; probably just me but maybe take a look and see if you can make it easier on the ICE-impaired? - the last para of section 3 was unexpected - would it be better elsewhere? Such as after initial offers are explained? - in 4.1 would s/highly receommended/highly RECOMMENDED/ be better 2119-wise? - 4.1 last para, be good to reference the section of whatever RFC defines Ta (5245 section 16 I guess) - when I searched RFC 5389 I didn't find the string " Ta " which confused me. - end of 4.3 talks about a "passive" attribute value but the ABNF in 4.5 uses abbreviations "act", "pass" and "so." Why the inconsistency? "Pass" might also be confusing (e.g. vs. "fail"). Maybe saving those few bytes isn't worth it? - 5.2: "Server reflexive active candidates can be derived from passive or S-O candidates by using the same IP address as a passive or S-O server reflexive candidate from the same interface has." Seems like a broken sentence. - 7.2 Is "on the base of any TCP candidate" going to be clear to readers? Its not that clear to me but then I'm not familiar with ICE really, so it might just be me. - I guess I wonder how common STUN shared secrets are in the wild. Is this really a practical mitigation? Would it make sense to note this and to say that appication layer security ought be used since its unlikely one can really ensure that there is no bad actor involved if using ICE? (This isn't a DISCUSS on the basis, that you're probably hosed or don't care without that application layer security but I guess a lot of media applications understand this nowadays.) - Section 12 typo: s/Same considerations apply/The same considerations apply/
(Stewart Bryant; former steering group member) No Objection