Re: [dispatch] [Ice] New version of the proposed charter

["Pal Martinsen (palmarti)" <[e-mail]>]

> On 09 Sep 2015, at 19:55, Ben Campbell <[e-mail]> wrote:
> 
> Comments inline:
> 
> On 2 Sep 2015, at 7:21, Marc Petit-Huguenin wrote:
> 
>> Please find below a new version of the proposed charter, trying to take in account all the comments so far.
>> 
>> The discussions are taking place in the ice mailing-list, please do not cross-post.
>> 
>> Thanks.
>> 
>> - ---------------------------------------------------------------------------------
>> 
>> Charter for Working Group
>> 
>> Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. ICE was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web.
>> 
>> Interactive Connectivity Establishment (ICE) is at the same time a NAT traversal technique, a multihomed address selection technique, and a dual stack address selection technique that works by including a multiplicity of IP addresses and ports in both the request and response messages of a connectivity establishment transaction. The IP addresses and ports provided by each side are paired and tested by peer-to-peer connectivity checks until one of these pair is selected to transport data. ICE follows the end to end principle where the clients themselves discovers, test and choose the network path to use. It makes no assumptions regarding network topology on the local or remote side.
>> 
>> ICE was originally defined for the Offer-Answer (RFC 3264) protocol used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and other realtime media establishment protocol have used the protocol. ICE is also used by non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC 6940).
>> 
>> The goal of the ICE Working Group is to consolidate the various initiatives to update ICE to make it more suitable for the WebRTC environment but also to all the current usages of ICE.
> 
> I'd like to see more specifics here. There are three milestones--the charter text should describe the work items supported by those milestones and expected output. If those milestones are assumed to be based on existing drafts, please name them.
> 
Ok. Will add some more description of active work. This will be based on adopted ICE work in MMUSIC.

Will also try to add some description of what I think the group is working on based on interest in non adopted drafts. This will be subject to my interpretation so some bashing must be done.


> We also need to be clear on how open or closed ended this is. Is the goal to finish specific work and close?
> Or do you expect the wg to add new work items in the future as new ICE requirements become apparent? (Note that a “standing" maintenance working group may get more charter scrutiny than one intended to finish and close.)
> 

My personal preference on this will be to accept work that proposes small changes to improve ICE in subtle ways. And my gut feeling is that we are starting to see the end of this work with the passive-agressive, continuous nomination and shaved ICE initiatives. I would expect those ideas will be trickling in for another year or two. But once that is finished I think it would be suitable to claim victory and close the WG. 

Updated charter will be sent out shortly.

.-.
Pål-Erik

> 
>> ICE is an application controlled protocol that leverages a set of network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and related protocol work done in the TRAM working group must be closely synchronised with the work in this working group. Synching with other network related working groups to make sure existing mechanisms like QoS, congestion control and other networking mechanisms still work would be essential if we want to improve how ICE works (MIF, TAPS, TSWG, HOMENET, etc...). From the application side, the users of ICE, there is a need to make sure what is specified is actually usable. Getting input from the application working groups will be essential (RTCWEB, HIP, MMUSIC, P2PSIP).
>> 
>> Milestones
>> 
>> Jun 2016 Submit Dual-stack Fairness with ICE as Proposed Standard
>> Apr 2016 Submit a revision of ICE (RFC 5245) as Proposed Standard
>> Jan 2016 Submit Trickle ICE as Proposed Standard
>> 
>> - --
>> Marc Petit-Huguenin
>> Email: [e-mail]
>> Blog: http://blog.marc.petit-huguenin.org
>> Profile: http://www.linkedin.com/in/petithug
>> 
>> _______________________________________________
>> Ice mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ice
> 
> _______________________________________________
> Ice mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ice