* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ice Status Pages

Interactive Connectivity Establishment (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2015-Oct-06 —  
Chairs
 
 


IETF-99 ice minutes

Session 2017-07-20 1330-1530: Berlin/Brussels - Audio stream - ice chatroom

Minutes

minutes-99-ice-00 minute



          #  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:
          
          ## 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
          
          



Generated from PyHt script /wg/ice/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -