Meeting minutes of ICE WG at IETF 99

Chairs: Ari Keränen & Flemming Andreasen

Note takers: Nils Ohlmeier & chairs

Jabber relay: Jonathan Lennox

WG status

Dual-stack fairness in RFC editor queue waiting for ICE-bis.

Trickle ICE completed WGLC. Next: publication request.

Agenda bash

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 issues

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

After nomination

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.

1: Selected Pair, Selected Candidate Pair definition

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

2: An agent SHOULD gather server reflexive and relayed candidates

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

3: An agent MUST support the backwards compatibility mode for the Binding

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.

4: The RECOMMENDED values for type preferences

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

5: When choosing type preferences, agents may take into account

Move to explanatory text to an appendix and reference it

6: The check list is neither Completed yet nor Failed yet

Looks good to most people

7: The agent pairs each local candidate with each remote candidate for

Jonathan: “IP address” is wrong it should be “IP address family” New text appears to be okay. Need to include NAT64 recommendations.

8: The priority attribute MUST be included in a Binding request and be

Approved

9: If the request had included a USE-CANDIDATE attribute

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.

10: If the response was the result of a triggered check

Approved

11: In certain usages of ICE, both agents may end up choosing

Merge with given one example of how this could happen (like 3PCC)

12: When ICE concludes, a lite agent can free host candidates

Christer & Jonathan will read this and make sure it's OK

Cullen: concerns that is changes behavior

13: A full agent SHOULD NOT stop sending checks and responses

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.

14: An agent MAY restart ICE for existing media streams

Christer: The new text is not clear enough

Suggestions for improvement in Github

15: If an agent wants to change the destinations of media streams

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.

16: An agent sends media from the base of the local candidate to the

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.

17: The selected pair for a component of a media stream is

Skipped because Peter put the original text back in

18: ICE has interactions with jitter buffer adaptation mechanisms

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

20: It is RECOMMENDED that, when an agent receives an RTP packet

Keep as is

21: for all streams, within an ICE session. The ICE agent MUST NOT change.

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

STUNbis discussion

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