Re: [tram] TRAM rechartering

Oleg Moskalenko <mom040267@gmail.com> Fri, 11 September 2015 15:46 UTC

Return-Path: <mom040267@gmail.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 EDCF11B4E1C for <tram@ietfa.amsl.com>; Fri, 11 Sep 2015 08:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 O3mCYFciOZ72 for <tram@ietfa.amsl.com>; Fri, 11 Sep 2015 08:46:13 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 970A11B4E1E for <tram@ietf.org>; Fri, 11 Sep 2015 08:46:13 -0700 (PDT)
Received: by padhy16 with SMTP id hy16so78186458pad.1 for <tram@ietf.org>; Fri, 11 Sep 2015 08:46:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yWyZHqC0Cv6lr2TcB/gu6AWH44QK5hpcqh/hRW+8PNY=; b=yfDFN6bJNc4e9tfHyY77QGhPHPGByd2Av9cVXaikFcGgOrlPXdHF62FRELosQQHSF6 HpOAVt2nqS+mrTUWKHgyqFUDdUOZEXwo9oQqM5bv9UJ2DzHkSh60cTomg8z78Zb2SV+P HdefSiVQj2OVmrJ0cW+0DSDSG2RFNDgA4h4c7t6l62hsq8y8ZloTkIQdL1ZdqvH5WOlQ DrQe24ijvGnnV0ZhFwYLU+2VTUlzBMybFWBw1dXv7Cz4z7YPKZtmDlmvUo5HjDWuBge7 hUZBZ0uqSUCsf9vjL9qeIiFdNQKEyPluw+7YNj7aDafWKVBSi9PuFkTNDRbjs8tdVvWT SMsQ==
X-Received: by 10.68.226.134 with SMTP id rs6mr97451969pbc.11.1441986373242; Fri, 11 Sep 2015 08:46:13 -0700 (PDT)
Received: from [10.0.0.115] ([216.241.194.52]) by smtp.gmail.com with ESMTPSA id jv5sm1077372pbc.47.2015.09.11.08.46.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Sep 2015 08:46:12 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Oleg Moskalenko <mom040267@gmail.com>
X-Mailer: iPhone Mail (13A340)
In-Reply-To: <55F2DA14.3040008@jive.com>
Date: Fri, 11 Sep 2015 09:48:15 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <D99136D1-9E3C-44E7-9A1B-76D5032D5AC9@gmail.com>
References: <55F2DA14.3040008@jive.com>
To: Simon Perreault <sperreault@jive.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/NjDkoyllSmhcYK4cbxs90tqf-tk>
Cc: "tram@ietf.org" <tram@ietf.org>
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: Fri, 11 Sep 2015 15:46:15 -0000

The mobility draft is a solid document  for mobile networks and working on is a good idea.

Oleg

Sent from my iPhone

> On Sep 11, 2015, at 7:41 AM, Simon Perreault <sperreault@jive.com> wrote:
> 
> 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.
> 
> 
> 
> <diff.html>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram