Interactive Connectivity Establishment
charter-ietf-ice-01

Changed charter milestone "Submit Dual-stack Fairness with ICE as Proposed Standard draft-ietf-mmusic-ice-dualstack-fairness", set description to "Submit Dual-stack Fairness with ICE as Proposed Standard ", added draft-ietf-mmusic-ice-dualstack-fairness to milestone

Changed charter milestone "Submit a revision of ICE (RFC 5245) as Proposed Standard draft-ietf-mmusic-rfc5245bis (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC) ", set description to "Submit a revision of ICE (RFC 5245) as Proposed Standard  (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC) ", added draft-ietf-mmusic-rfc5245bis to milestone

Changed charter milestone "Submit Trickle ICE as Proposed Standard draft-ietf-mmusic-trickle-ice (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC)", set description to "Submit Trickle ICE as Proposed Standard  (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC)", added draft-ietf-mmusic-trickle-ice to milestone

[Ballot comment]

I like the idea of working to ensure we don't have another fuss
about exposing the various IP addresses when that's not wanted.
I'm not sure if that needs to be in the charter or not.

[Ballot comment]
Yes with one question and one comment:

- Does the item "congestion control" include the topic of pacing ICE? ICE pacing has been discussed in the past and I am not sure that this has been dealt with in the past or if this is being include in the scope of the ICE WG as a work topic?

- Please remove the PPSP WG as this WG will be closed soon, i.e., as soon as the last draft is with the RFC editor.

[Ballot comment]
The charter is fine as-is, but I would have expected some mention of security as the referenced RFC goes into detail about a number of possible attacks.  I put this down as no objection since much of the solution will rely on the protocol this is used for - WebRTC or SIP in the case of the referenced RFC.  As long as security is addressed in drafts produced, maybe mention isn't needed in the charter.

[Ballot comment]
Just a question for my own edification... How does the address selection mechanism in ICE work/play with the address selection done at the IP layer?  We have address selection mechanisms described in RFCs 6724 and 6555 (and others) and address selection issues/requirements described in RFCs 5220 and 5221.  Not sure how all those fit with a higher-layer protocol making similar decisions.

[Ballot comment]
This is the right thing to do, and I'm fine with the application level work being in ART/ICE while the tooling work remains in TSV/TRAM.

I do have one minor comment - is "fairness" the best word that can be used to describe these deliverables? In TSV, it usually means fairness between competing flows, and seems confusing here, at least to me. This seems more like "improved selection" or something.