TCP Candidates with Interactive Connectivity Establishment (ICE)
RFC 6544

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

(Gonzalo Camarillo) Yes

(Wesley Eddy) Yes

(David Harrington) Yes

(Robert Sparks) Yes

Comment (2011-11-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Jari Arkko) (was Discuss) No Objection

Comment (2011-11-03)
No email
send info
Thank you fow writing this document. It is a complex topic but the document was quite easy to read.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2011-11-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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 

(Stephen Farrell) (was Discuss) No Objection

Comment (2011-10-30)
No email
send info
- 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

- 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

- 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/

(Russ Housley) (was Discuss) No Objection

(Pete Resnick) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Sean Turner) No Objection

Comment (2011-11-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support Stephen's discuss.