Re: [tram] TRAM rechartering

"Hutton, Andrew" <andrew.hutton@unify.com> Mon, 14 September 2015 08:13 UTC

Return-Path: <andrew.hutton@unify.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E2F1B51EB for <tram@ietfa.amsl.com>; Mon, 14 Sep 2015 01:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Fdxz79b1RfW0 for <tram@ietfa.amsl.com>; Mon, 14 Sep 2015 01:13:46 -0700 (PDT)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7845F1B4803 for <tram@ietf.org>; Mon, 14 Sep 2015 01:13:46 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 0B21F23F0430; Mon, 14 Sep 2015 10:13:45 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0248.002; Mon, 14 Sep 2015 10:13:42 +0200
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: Simon Perreault <sperreault@jive.com>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] TRAM rechartering
Thread-Index: AQHQ7Jeg8tBqOG+gI0anSWzE58lWWp47sUQA
Date: Mon, 14 Sep 2015 08:13:42 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E86AE19@MCHP04MSX.global-ad.net>
References: <55F2DA14.3040008@jive.com>
In-Reply-To: <55F2DA14.3040008@jive.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/si2UDUtTd3gxJ2QPSyih1844P3Y>
Subject: Re: [tram] TRAM rechartering
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2015 08:13:48 -0000

Looks good to me.

Andy

> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault
> Sent: 11 September 2015 14:42
> To: tram@ietf.org
> Subject: [tram] TRAM rechartering
> 
> TRAMsters,
> 
> We would like to get some feedback on a proposed rechartering. The goal
> is to be able to explicitly describe some new work that would be taken
> on by the working group.
> 
> The two drafts considered are:
> 
> - draft-petithuguenin-tram-stun-pmtud-01
> - draft-wing-tram-turn-mobility-03
> 
> Charter proposal follows. Diff attached. As you'll see the changes are
> very minimal. If the new charter is adopted then corresponding
> milestones will be created.
> 
> The question we are asking is: are these two new work items things that
> you want to be working on? The PMTUD draft was presented in Prague and
> the consensus seemed to be positive. As for the mobility draft, it has
> been active for a long time and now we are asking the TRAMsters
> directly
> if they want to work on it.
> 
> Thoughts?
> 
> Thanks,
> Simon & Gonzalo
> 
> 
> > Traversal Using Relays around NAT (TURN) was published as RFC 5766 in
> > April 2010. Until recently the protocol had seen rather limited
> > deployment. This is largely because its primary use case is as one
> > of the NAT traversal methods of the Interactive Connectivity
> > Establishment (ICE) framework (RFC 5245), and ICE itself was slow
> > to achieve widespread adoption, as other mechanisms were already
> > being used by the VoIP industry. This situation has changed
> > drastically as ICE, and consequently TURN, are mandatory to implement
> > in WebRTC, a set of technologies developed at the IETF and W3C to
> > standardize Real Time Communication on the Web.
> >
> > Together with the arrival of WebRTC, there is a renewed interest in
> > TURN and ICE, as evidenced by recent work updating the ICE framework
> > (still in progress), and standardizing the URIs used to access a STUN
> > (RFC 7064) or TURN (RFC 7065) server.
> >
> > The goal of the TRAM Working Group is to consolidate the various
> > initiatives to update TURN and STUN to make them more suitable for
> > the WebRTC environment. The work will include authentication
> mechanisms,
> > a path MTU discovery mechanism, an IP address mobility solution for
> > TURN, and extensions to TURN and STUN. The Working Group will closely
> > coordinate with the appropriate Working Groups, including RTCWEB,
> > MMUSIC, and HTTPBIS.
> >
> > In developing upgrades to TURN, the group will consider the passive
> > monitoring risks introduced by the centralization of call traffic
> > through a TURN server. When such risks arise, they will recommend
> > appropriate mitigations. For example, a mechanism for directing
> traffic
> > to a TURN server other than one configured by the application could
> be
> > used to direct calls through a TURN server configured to do
> monitoring.
> > When such a mechanism is used, it is important that the endpoints to
> the
> > call apply end-to-end encryption and authentication to ensure that
> they
> > are protected from the TURN server.
> 
>