TCP Candidates with Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-tcp-16
Yes
(David Harrington)
(Gonzalo Camarillo)
(Wesley Eddy)
No Objection
(Dan Romascanu)
(Pete Resnick)
(Peter Saint-Andre)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
Note: This ballot was opened for revision 16 and is now closed.
David Harrington Former IESG member
Yes
Yes
()
Unknown
Gonzalo Camarillo Former IESG member
Yes
Yes
()
Unknown
Robert Sparks Former IESG member
Yes
Yes
(2011-11-01)
Unknown
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 IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2011-11-02)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2011-11-03)
Unknown
Thank you fow writing this document. It is a complex topic but the document was quite easy to read.
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2011-11-01)
Unknown
I support Stephen's discuss.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2011-10-30)
Unknown
- 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 IESG member
No Objection
No Objection
()
Unknown