Note: This ballot was opened for revision 04 and is now closed.
I support Ben Kaduk's position on clarifying the state machine. Thank you for the discussion I saw addressing that issue. Beyond that, editorial nits only: -- Section 3.1. Editorial. Per “It is entirely legal for …”, seems colloquial. Perhaps, “Per RFCXXX, an ICE agent could provide zero candidates of its own” -- Section 5. Typo. s/an backup mechanism/a backup mechanism/
Thanks for addressing my Discuss point! I trust that the duplicated sentence ("As a result, [...]") can be handled by an RFC Editor Note.
Like Eric (and others) I think making a change to trickle before it becomes an RFC would be as better idea than Update'ing it in this way. I also think it would be really useful for the Abstract to have a sentence saying (in a very high level way *how* this updates RFC8445 e.g: This document updates RFC8445 by requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs left". This makes it clear to implementors if/why they need to read this document.
Thank you for this short and easy to read document. But, I cannot refrain from wondering about this part as the trickle-ice I-D is still in RFC editor queue => easier to fix it in the body of the trickle-ice IMHO (could be wrong): "[RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-ietf-ice-trickle once it has been published. Please also indicate that this specification updates RFC XXXX.]" I also wonder why section 1 talks about 'race conditions' while the issue is related to a too short default time-out or in the use cases of section 3. (in my mind, 'race conditions' is an unusual sequence of events). Explanations will be welcome (albeit not blocking). -éric