TURN Revised and Modernized
charter-ietf-tram-02

Added milestone "Send new TURN server discovery mechanism for enterprises and ISPs to IESG for publication as Proposed Standard", due November 2015, from current group milestones

[Ballot comment]
My substantive point has to do with the scoping and use cases being dealt with in TRAM. I feel like some of the confusion over the TRAM drafts has related to whether the mechanisms being specified are expected to be used only within the WebRTC context or outside of it as well, for STUN/TURN generally. I'd like to see a commitment to clarity in this regard called out in the charter. E.g., "In making updates to TURN and STUN, the working group will clearly document the motivations and implications of the updates both within the WebRTC context and more broadly" or something like that.

[Ballot comment]
I agree with Alissa's confusion (the tracker says internal review but the ballot says external) and comment.

Also, if this is for external review, some milestones would be nice.

[Ballot block]
I'm a little confused. Is the charter going for external review or not? Or is the IESG being asked to comment on whether it should go for external review or not? If it were going for external review I would have put my point below in a comment. But if this is the last opportunity for the IESG to weigh in on this then I'd like to see the point below discussed. I don't think this charter needs to go for external review.

My substantive point has to do with the scoping and use cases being dealt with in TRAM. I feel like some of the confusion over the TRAM drafts has related to whether the mechanisms being specified are expected to be used only within the WebRTC context or outside of it as well, for STUN/TURN generally. I'd like to see a commitment to clarity in this regard called out in the charter. E.g., "In making updates to TURN and STUN, the working group will clearly document the motivations and implications of the updates both within the WebRTC context and more broadly" or something like that.

[Ballot comment]
It might be nice to add a little bit of text here regarding the potential of TURN to facilitate passive monitoring of voice calls.  Some notional text:
"""
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. 
"""

[Ballot comment]
I am going to be chairing this. I am not sure if I should recuse myself because of that. I am logging no objection but if you want me to recuse, I can do that as well.

[Ballot comment]
While I disagree with Richard's Block because (IMHO) milestones are entirely at the discretion of the WG chairs and responsible AD as a management tool for operating the WG, it is exactly that point that makes me wish this charter included a broader discussion of work items and deliverables. My experience is that WGs that are chartered with such an open remit run into trouble later when "there is nothing in our charter that prevents us from doing foo." The defence that "no reasonable WG would ever do that" never actually seems to apply.

Thus, I would really appreciate it if you added more scope and direction to the charter both to restrict future wildness and to help guide current work.

[Ballot block]
I'm going to be the guy that harps on milestones.  For the most part these are sensible, but I'm skeptical of the "discovery for ISPs and enterprises" milestone.  The only use case for this that comes to mind is pervasive monitoring of RTP sessions.  If one of the proponents can explain what purpose this feature would serve that merits the monitoring risk, I'll clear.

[Ballot block]
I'll likely clear on or before the call, but I just want to make sure you're just specify DTLS as an authenticated transport mechanism not mucking about with it somehow.

[Ballot comment]
Nicely written charter, thanks.

It may be helpful to call out the deliverables more precisely (although) the milestones may do this well enough. It is not quite clear from this whether there are precisely two deliverables (TURN and STUN updates) or whether additional specific deliverables are intended.

[Ballot block]
  The goal of the TRAM Working Group is to consolidate the various initiatives to
  update TURN and STUN, including the definition of new transport, authentication
  mechanisms, and extensions, that make STUN and TURN more suitable for the WebRTC
  environment.

That sentence is overly complicated, and makes some referents unclear.  Fixing it properly might actually resolve my blocking point, which could come from a misunderstanding of that sentence.  Here's my first stab at fixing it, but there's a "fill in here" spot in it:

NEW
  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 the definition of new transport protocols,
  authentication mechanisms, and extensions [TO WHAT?].
END

On "including the definition of new transport": is it really in scope for TRAM to define new transport protocols?  Do we really need another SCTP or DCCP, which will have all the deployability problems that those have?

[Ballot comment]
And then just some editorial stuff:

  WebRTC, which is a set of technologies developed
  at the IETF and W3C aiming to enable Real Time Communication on the Web.

I always dislike the "aiming" bit, and we do have RTC on the web today.  So how about:

NEW
  WebRTC, which is a set of technologies developed
  at the IETF and W3C that standardizes Real Time Communication on the Web.
END

  Because of the ubiquity of the Web and of the new opportunities created by the
  arrival of WebRTC,  there is a renewed interest in TURN and ICE

Can we just cut the "ubiquity of the Web" stuff, really?

NEW
  The new opportunities created by WebRTC,  have sparked a renewed interest
  in TURN and ICE
END