Re: [MMUSIC] [Ice] ICE WG Charter version 2 (Proposed changes)

On 25/09/15 12:18, Pal Martinsen (palmarti) wrote:
> Hi,
>
> Based on mailing-list discussions i propose the following changes:
> (A pull request can be found at: https://github.com/petithug/icewg/pull/5)

This works for me. I added couple of editorial comments in the github 
pull request.

Cheers,
Ari

> - Merge section 1 and 3. Moved former 2 to 1.
> Better introduction to what ICE is and having all the history in the
> same section. The intended effect of the edit is to emphasise the
> versatility of ICE and maybe attract more “network” people to attend
> join the wg.
>
> - Rewrote the start of the goal section to pass strict parsers.
> “The goal of the ICE Working Group is to consolidate the various
> initiatives to update and improve ICE, and to help ensure suitability
> and consistency in the environments ICE operates in.”
>
> I wanted to remove webRTC from the sentence. If WG FOO comes with the
> same amount of positive energy to help improve ICE  I think it would
> deserve to get the same amount of attention.
>
>
> The charter would then look like:
>
> Charter for Working Group
>
> 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. It makes no
> assumptions regarding network topology on the local or remote side.
>
> Interactive Connectivity Establishment was published as RFC 5245 in
> April 2010. Until recently the protocol had seen rather limited
> deployment. 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. 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 and improve ICE, and to help ensure suitability
> and consistency in the environments ICE operates in. Current work in
> this area includes an updated version of the ICE RFC (ICEbis), Trickle
> ICE and dualstack/multihomed fairness. It is worth noticing that this
> work will make ICE more flexible, robust and more suitable for changing
> mobile environments without major changes to the original ICE RFC. The
> ICE workgroup will consider new work items that follow this pattern.
>
> 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
> synchronized with the work in this working group. To avoid
> interoperability issues and unwanted behavior it is desired to increase
> the interaction with other working groups dealing with network protocols
> closer to the wire. Example of such work may be, but not limited to;
> issues regarding multi-homing, multi subnet and prefixes, QoS, transport
> selection and congestion control. 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
> helpful (RTCWEB, HIP, MMUSIC, P2PSIP, PPSP).
>
>
> .-.
> Pål-Erik
>
>
>
>
>
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>