[tram] TRAM rechartering

[Simon Perreault <[e-mail]>]

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.