Re: [Ice] ICE WG Charter version 2 (Proposed changes)
"Ben Campbell" <ben@nostrum.com> Mon, 28 September 2015 19:54 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 311441B2C40; Mon, 28 Sep 2015 12:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Nc3AZRdlpj92; Mon, 28 Sep 2015 12:54:49 -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 76A291B2C41; Mon, 28 Sep 2015 12:54:49 -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 t8SJsPZZ015210 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Sep 2015 14:54:35 -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>, Marc Petit-Huguenin <petithug@acm.org>
Date: Mon, 28 Sep 2015 14:54:25 -0500
Message-ID: <E9DCF74F-E8D8-4D30-8210-BE7EA0C6FE09@nostrum.com>
In-Reply-To: <C5E17AE1-DDED-4FC1-8BA6-D2D811B77FFD@cisco.com>
References: <C5E17AE1-DDED-4FC1-8BA6-D2D811B77FFD@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/hyzFVsGjRaJD-Mj-bGiKHo8b4D0>
Cc: mmusic <mmusic@ietf.org>, ice@ietf.org
Subject: Re: [Ice] ICE WG Charter version 2 (Proposed changes)
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: Mon, 28 Sep 2015 19:54:51 -0000
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: > https://github.com/petithug/icewg/pull/5) > > - 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
- [Ice] ICE WG Charter version 2 (Proposed changes) Pal Martinsen (palmarti)
- Re: [Ice] ICE WG Charter version 2 (Proposed chan… Ari Keränen
- Re: [Ice] ICE WG Charter version 2 (Proposed chan… Ben Campbell
- Re: [Ice] ICE WG Charter version 2 (Proposed chan… Ben Campbell
- Re: [Ice] ICE WG Charter version 2 (Proposed chan… Marc Petit-Huguenin
- Re: [Ice] ICE WG Charter version 2 (Proposed chan… Harald Alvestrand