Re: [Ice] Updated charter

"Ben Campbell" <ben@nostrum.com> Fri, 18 September 2015 20:37 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16E51B34EB for <ice@ietfa.amsl.com>; Fri, 18 Sep 2015 13:37:08 -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 Jjfv6dtFZS-M for <ice@ietfa.amsl.com>; Fri, 18 Sep 2015 13:37:07 -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 44D791B34EA for <ice@ietf.org>; Fri, 18 Sep 2015 13:37:07 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8IKat5Q064426 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 Sep 2015 15:37:05 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: Pal Martinsen <palmarti@cisco.com>
Date: Fri, 18 Sep 2015 15:36:34 -0500
Message-ID: <C5ED98ED-D169-475A-8FF5-824A8A0BEC33@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/ice/BVJMAzBWe06pDvL_n_8RvvHj1JQ>
Cc: ice@ietf.org
Subject: Re: [Ice] Updated charter
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" <ice.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ice>, <mailto:ice-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ice/>
List-Post: <mailto:ice@ietf.org>
List-Help: <mailto:ice-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ice>, <mailto:ice-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2015 20:37:09 -0000

For the record, this version addresses my previous comments. IMO it 
looks good to go, modulo the separate discussion about the scope of the 
work. (much of which could be adopted post-chartering under the "new 
work items that follow this pattern" clause.)

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