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

"Ben Campbell" <> Tue, 29 September 2015 01:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1C9B71B2D11; Mon, 28 Sep 2015 18:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z1lPdfJyrf9N; Mon, 28 Sep 2015 18:28:05 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A9FD1B2D15; Mon, 28 Sep 2015 18:28:05 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id t8T1RpCI042591 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Sep 2015 20:28:01 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
To: Pal Martinsen <>, Marc Petit-Huguenin <>
Date: Mon, 28 Sep 2015 20:27:51 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <>
Cc: mmusic <>,
Subject: Re: [MMUSIC] [Ice] ICE WG Charter version 2 (Proposed changes)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Sep 2015 01:28:07 -0000

I went ahead and updated this in the tracker, since the IESG review is 
coming up soon. I made a few of very minor edits. Please take a look and 
let me know asap if anything doesn't look right.



On 28 Sep 2015, at 14:54, Ben Campbell wrote:

> I think this version looks good enough for the IESG internal review. 
> Unless I see an objection really soon now, I will update the charter 
> in the datatracker to match.
> Thanks!
> Ben.
> On 25 Sep 2015, at 4:18, Pal Martinsen (palmarti) wrote:
>> Hi,
>> Based on mailing-list discussions i propose the following changes:
>> (A pull request can be found at: 
>> - 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 mailing list