Re: [MMUSIC] [Ice] Updated charter

"Ben Campbell" <ben@nostrum.com> Tue, 22 September 2015 17:38 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FAF1A92AB; Tue, 22 Sep 2015 10:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz6FAt8s5jhY; Tue, 22 Sep 2015 10:38:20 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DC81A9245; Tue, 22 Sep 2015 10:38:19 -0700 (PDT)
Received: from [172.20.10.2] (mobile-166-173-187-116.mycingular.net [166.173.187.116]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8MHc68v067051 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Sep 2015 12:38:12 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-187-116.mycingular.net [166.173.187.116] claimed to be [172.20.10.2]
From: Ben Campbell <ben@nostrum.com>
To: ice@ietf.org, mmusic <mmusic@ietf.org>
Date: Tue, 22 Sep 2015 12:38:01 -0500
Message-ID: <94DE3665-DAEC-4AC1-8DBE-F8DAAD10BFE3@nostrum.com>
In-Reply-To: <537316C7-310F-477A-A639-B3D2E7655727@cisco.com>
References: <537316C7-310F-477A-A639-B3D2E7655727@cisco.com>
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: <http://mailarchive.ietf.org/arch/msg/mmusic/okyQb6zz6HNbkYdZJ52XegZcmCo>
Cc: mmusic-chairs@tools.ietf.org, mmusic <mmusic@ietf.org>, ice@ietf.org
Subject: Re: [MMUSIC] [Ice] Updated charter
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2015 17:38:22 -0000

Hi,

If we hope to have ICE approved as a working group in time for Yokohama, 
we would need to start the IESG internal review by this Thursday. IMO, 
this language is about right. I think there's still an open issue about 
where the SDP bit lives. Can we close on that?

Thanks!

Ben.

On 16 Sep 2015, at 7:17, Pal Martinsen (palmarti) wrote:

> Hi,
>
> Based on list discussion the charter is now updated.
> For the github draft enthusiasts out there the pull request can be 
> found at:
> https://github.com/petithug/icewg/pulls.
>
> —————— Start —————-
> 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. 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).
>
>
>
> Milestones
>
> - Jan 2016 Submit Dual-stack Fairness with ICE as Proposed Standard
> draft-ietf-mmusic-ice-dualstack-fairness
> - Apr 2016 Submit a revision of ICE (RFC 5245) as Proposed Standard
> draft-ietf-mmusic-rfc5245bis
> (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC)
> - Jan 2016 Submit Trickle ICE as Proposed Standard
> draft-ietf-mmusic-trickle-ice
> (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC)
>
> ————— STOP ———————
>
> .-.
> Pål-Erik
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice