Subject: Re: [tram] TRAM rechartering

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 7 Oct 2015 21:42:01 +0000

+1

.-.
Pål-Erik

On 11 Sep 2015, at 11:01, Ram Mohan R (rmohanr) <[email-masked]<mailto:[email-masked]>> wrote:

+1

I also support both these work items.

Ram

From: tram <[email-masked]<mailto:[email-masked]>> on behalf of Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Date: Friday, 11 September 2015 10:21 pm
To: "Gonzalo Salgueiro (gsalguei)" <[email-masked]<mailto:[email-masked]>>
Cc: Simon Perreault <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] TRAM rechartering

+1

On Fri, Sep 11, 2015 at 8:51 AM, Gonzalo Salgueiro (gsalguei) <[email-masked]<mailto:[email-masked]>> wrote:
+1

-G

> On Sep 11, 2015, at 11:50 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
>
> I support both the work items.
>
> -Tiru
>
>> -----Original Message-----
>> From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Simon Perreault
>> Sent: Friday, September 11, 2015 6:42 AM
>> To: [email-masked]<mailto:[email-masked]>
>> 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.
>>
>>
>
> _______________________________________________
> tram mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram