Re: [Ice] Peter's review of ICEbis

[Christer Holmberg <[e-mail]>]

Hi,

To anyone who is going to comment on Peter's e-mail: I suggest using SEPARATE THREADS for each issue (please indicate in the subject what the thread is about) – otherwise we are going to end up in a big mess.

Regards,

Christer

From: Ice <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Friday 26 May 2017 at 13:26
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Ice] Peter's review of ICEbis

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?).