Re: [tram] TRAM rechartering

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

I support both the work items. 

-Tiru

> -----Original Message-----
> From: tram [mailto:[e-mail]] On Behalf Of Simon Perreault
> Sent: Friday, September 11, 2015 6:42 AM
> To: [e-mail]
> 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.
> 
>