[Ice] Peter's review of ICEbis

[Peter Thatcher <[e-mail]>]

I have read through ICEbis (which took a very long time because it is very
long) and have the following questions and comments:

- If we remove lower-priority candidate pairs across check lists, what
happens if a certain check list is starved because all of its candidate
pairs are lower priority?  One option might be to say the limit is per
check list.  Another is to recognize that it might happen but live with it.

- The spec says it's only defined for one TURN server and one STUN server
but then it says what to do when more than one TURN server or STUN server
is used.  I'm guessing we should remove the part about one TURN server
rather than the other way around.

- Why do we nominate by putting the valid pair in the triggered check
queue?  Why not just say "send a binding request"?  In particular reason?
Do we *want* it to be delayed if there are many things in the front of the
queue?

- Much of the spec is much more complicated than it otherwise would be
because a media stream has more than one component.  Would it make sense to
define a check list as representing a single component of a single media
stream rather than multiple components?  That would make the rules and
states around check lists much more simple.

- Should we keep this "send another candidate exchange when you're
Complete" thing?  It looks like it's just there to let signaling servers
learn something, which I think should be out of scope for this document.
Let a SIP document specify that.

- Why can't a lite agent start an ICE restart or remove a media stream?
Seems like it would make sense for it to be able to, but the spec says it
can't.

- Since we won't have aggressive nomination, do we still need the
"three-second rule" for when candidates can be freed?

- Why do we model valid candidate pairs as a separate list of separate
candidates from the normal check list?  Why not just say that some
candidate pairs are valid.  Why have this list of them?    Seems like we
could remove the concept.

- The concept of using a Data Indication for a keepalive seems outdated.
In RTCWEB, consent freshness requires the use of binding requests, not data
indications.    Should we change this?

- The one example in the doc uses aggressive nomination, which no longer
exists.

- What does the phrase "through good box and software security on TURN
servers." mean?

- Do we still need all the UNASF stuff?

- Do our "changes from 5245" section need to be updated?


Lastly, while reading through it I found things that could be removed or
moved or reworded along with grammar and style fixes.  Rather than listing
all of them here, I made a PR that has all of them:

https://github.com/ice-wg/rfc5245bis/pull/35/files

It's kind of big, but I think it's substantial improvement to clarity and
readability (else why would I spend the time on it?).