Chairs: Ari Keränen & Flemming Andreasen
Note takers: Nils Ohlmeier & chairs
Jabber relay: Jonathan Lennox
Dual-stack fairness in RFC editor queue waiting for ICE-bis.
Trickle ICE completed WGLC. Next: publication request.
Objective of the meeting: Finalize ICE-bis.
No objections against 2 hours of bashing on the one remaining pull request:
https://github.com/ice-wg/rfc5245bis/pull/38
ICE state: Lets keep it
Check list state & check list status: Check list status can be removed, pending double check.
ICE priorities: Only uniqueness per stream is required
Christer: You should be able to re-nominate after nomination and switch
Nils: What to do with the not nominated pairs after nomination?
Following issues are from the pull request #38. Numbers before issue reference to instances of "for IETF 99 session" in the pull request comments. The issue text refers to text from the draft.
Jonathan: was there normative text saying to throw away packets on non-nominated pairs?
Cullen: we switch pairs without restart
Jonathan: no after selection you need a restart to switch the selected pairs
Christer: this comes down to the question if you can re-nominate during an ICE session
Christer & Peter: Needs to be checked against the rest of the spec
Is this only editorial?
Nils: I think it’s okay to reduce this paragraph to one sentence
Ben: every SHOULD should have an explanation, to avoid questions in IESG review
Find a briefer and more accurate reason why SHOULD
Jonathan: only use multiple TURN servers if you believe they have different network characteristics
Nils: WebRTC allows to specify multiple TURN servers
Jonathan: Makes sense to use multiple if you believe they have different network characteristics (DMZ vs public, TCP vs UDP, etc.). Use same set of TURN servers across all your checklists and pick the same IP-address across all of them.
The limitation from the first sentence to a single server should go. Try to come up with better text how to handle multiple servers.
Cullen: can go either way (with or without the old text)
Jonathan: Existing text does not take dual-stack-fairness into consideration so a change is definitely needed.
Ben: some advice on why there is a SHOULD here
Move to explanatory text to an appendix and reference it
Move to explanatory text to an appendix and reference it
Looks good to most people
Jonathan: “IP address” is wrong it should be “IP address family”
New text appears to be okay. Need to include NAT64 recommendations.
Approved
Cullen: Seems like a non-editorial change - not clear if omission of the "unless..." part is correct or not.
Probably better in a media handling section
Cullen: this can happen in case STUN gets through the firewall which later blocks RTP
Conclusion: OK with the change, but we MUST add text somewhere else to deal with the scenario where media doesn't work subsequently.
Approved
Merge with given one example of how this could happen (like 3PCC)
Christer & Jonathan will read this and make sure it's OK
Cullen: concerns that is changes behavior
Cullen: Believe this is an RTCWeb thing - don't belive this is correct for the general ICE spec.
Jonatham: Believe this is also trying to handle forking
Conclusion: Safer to keep old text, but also need to consider forking. Old text has some confusing parts to it too as well (Completed part for example is not clear). So old text still need some updates. Christer will take a stab at updating.
Christer: The new text is not clear enough
Suggestions for improvement in Github
MAY appears to be a strange way to describe this is the only way to accomplish this
Cullen: change MAY to MUST
Nils: implementation level only occurs in this one sentence
replace “implementation level” with explicit description of full vs. lite
Conclusion: Change the MAY to MUST in the new text. Change "implementation level" to description of full/lite switch.
Looks good, except a missing “is”.
Cullen: is not sure if it is really equivalent
Cullen: Want to think more about it - not clear the old and new are equivalent. Due July 27.
Skipped because Peter put the original text back in
Jonathan: don't remove it all
Cullen: very important because it affects RTP and there is no other spec to reference to
Ben: maybe material to appendix, but can’t move normative text there
Conclusion: Keep as is
Keep as is
Jonathan: Elsewhere it says you do not change roles on an ICE restart. 3PCC is a challenge though - new party has now idea what the previous role was
Cullen: Not an editorial change. Will not interwork with old implementations.
Conclusion: keep as is
Jonathan: do we want to use STUNbis? It changes SHA1 to SHA256
Ben: Ask the Sec AD.
Not clear if the IESG will approve a spec without crypto agility at this point. If we do keep SHA-1, then will need to clearly cover it in the Security Considerations. Maybe ask the Sec AD to help write the security considerations if we keep it.
Christer: will ask a Sec AD about this and to provide a paragraph
Cullen: Need to ensure interoperability between ICE and ICEbis (in general). Do the new and old timing really match up?
Bring it to the list please