Subject: [tram] First post

From: Simon Perreault <[email-masked]>
Date: Fri, 15 Nov 2013 13:55:51 -0500

All,

Any objection against sending the following to rtcweb, pntaw, and 
behave? Any other lists that should be included?

Simon

====================

All,

A few of us have been working on a proposal for a new working group that 
would focus on enhancements to STUN and TURN. The proposed name is TRAM 
(Turn Revised And Modernized) and discussion is happening in 
<[email-masked]>.
Subscribe link: <https://www.ietf.org/mailman/listinfo/tram>

Here is the charter we have been working on. If you would like to 
comment and/or get involved, please do so on the TRAM mailing list.

Simon (and many others!)

> Turn Revised And Modernized (tram)
> ----------------------------------
>
> Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April
> 2010.  Until recently the protocol had only a rather limited deployment.  This
> is primarily because its primary use case is as one of the NAT traversal
> methods of the Interactive Connectivity Establishment (ICE) framework (RFC
> 5245).  This inherent dependency on ICE combined with the fact that ICE itself
> was slow to achieve widespread adoption because other alternative mechanisms
> were historically used by the VoIP industry were the causes of the initial
> lack of interest.  This situation has changed drastically as ICE, and
> consequently TURN, are mandatory to implement in WebRTC, which is a set of
> technologies developed at the IETF and W3C aiming to enable Real Time
> Communication on the Web.
>
> 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, as evidenced by
> the recent work updating the ICE framework, as well as standardizing the URIs
> used to access a STUN [RFC7064] or TURN [RFC7065] server.
>
> The goal of the TRAM Working Group is to consolidate the various initiatives
> to update TURN and STUN, including the definition of new transport and
> authentication mechanisms that make STUN and TURN more suitable for the WebRTC
> environment.  The Working Group will closely coordinate with the appropriate
> Working Groups, including RTCWEB, MMUSIC, and HTTPBIS.
>
> The current list of deliverable is:
>
> - DTLS transport for TURN
>
>   Candidate draft: draft-petithuguenin-tram-turn-dtls
>
>   TURN defines three transports: UDP, TCP, and TLS. A straightforward extension
>   of this set is DTLS, enabling secure datagram-oriented transport.
>
> - New authentication mechanism for TURN
>
>   Problem analysis: draft-reddy-behave-turn-auth
>   Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been suggested
>
>   The current authentication mechanism for TURN, which is reused from STUN, has
>   been designed with a SIP account database in mind. The new RTCWEB usages,
>   which are mostly based on web applications, do not fit that model. A new
>   authentication mechanism optimized for such web applications will be created.
>
> - TURN server auto-discovery mechanism for enterprise and ISPs
>
>   Candidate draft: TBD
>
>   Current TURN server discovery is based on the presence of SRV and/or NAPTR DNS
>   records. These records are usually under the administrative control of the
>   application or service provider, not the enterprise or the ISP on whose
>   network the client is situated. Enterprises or ISPs wishing to provide their
>   own TURN server, in an attempt to reduce so-called "triangle routing", need a
>   new auto-discovery mechanism.
>
> - STUN-bis
>
>   Candidate draft: TBD
>
>   A new revision of RFC 5389 will contain:
>
>   - Various bug fixes
>   - STUN hash algorithm agility (currently only SHA-1 is allowed)
>
> - TURN-bis
>
>   Candidate draft: TBD
>
>   A new revision of RFC 5766 will contain:
>
>   - Various bug fixes
>   - Support for multi-tenant servers
>     (Servers always send the same REALM attribute. No realm negotiation phase
>      currently exists.)
>
> Goals and Milestones:
>
> [TBD]

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 15 Nov 2013 11:01:24 -0800

MMUSIC has an interesting draft on TURN mobility (MICE) that I am watching
and I am going to implement. I wonder whether the authors of the draft may
be interested in the TURN evolution.

On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault <
[email-masked]> wrote:

> All,
>
> Any objection against sending the following to rtcweb, pntaw, and behave?
> Any other lists that should be included?
>
> Simon
>
> ====================
>
> All,
>
> (Turn Revised And Modernized) and discussion is happening in <
> [email-masked]>.
> Here is the charter we have been working on. If you would like to comment
> and/or get involved, please do so on the TRAM mailing list.
>
> Simon (and many others!)
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 15 Nov 2013 19:20:46 +0000

No objection. 

My main concern is that we have some element of agility with this work. The discussion over the past few days seem to indicate that we have a bunch of work that is not at all contentious and viewed as valuable by all. This work would likely get us a (BOF-less) WG stood up quickly and we have work in progress to address many of those milestones already. I just want to ensure we get all this work rolling along, rather than making WG formation dependent on issues known to be more contentious, requiring far more discussion and having many more dependencies on many different groups (i.e., HTTP traversal).  To be clear, I'm not saying lets not discuss these thing. I absolutely think they are important problems that need solving, but I think those discussions can happen in parallel and it would be highly inefficient to hold up all this other work on account of those interminable discussions.

Gonzalo

On Nov 15, 2013, at 1:55 PM, Simon Perreault <[email-masked]> wrote:

> All,
> 
> Any objection against sending the following to rtcweb, pntaw, and behave? Any other lists that should be included?
> 
> Simon
> 
> ====================
> 
> All,
> 
> A few of us have been working on a proposal for a new working group that would focus on enhancements to STUN and TURN. The proposed name is TRAM (Turn Revised And Modernized) and discussion is happening in <[email-masked]>.
> Here is the charter we have been working on. If you would like to comment and/or get involved, please do so on the TRAM mailing list.
> 
> Simon (and many others!)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Nov 2013 11:44:33 -0800

Gonzalo,

> My main concern is that we have some element of agility with this work. The discussion over the past few days seem to indicate that we have a bunch of work that is not at all contentious and viewed…

I understand your concern. And it seems the controversial element has 
been removed from the charter/milestones.

Are you suggesting that the TURN over websockets discussion happen on 
the TRAM list, but without a milestone? Or are you suggesting that the 
discussion needs to happen somewhere else?

	Thanks,
	Paul

---

From: Justin Uberti <[email-masked]>
Date: Fri, 15 Nov 2013 12:18:42 -0800

How does MICE impact TURN?

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 15 Nov 2013 12:21:56 -0800

MICE may be interesting for WebRTC on mobile devices. It allows a "mobile"
TURN client: when a mobile device is moving from tower to tower, it may
change its IP address; but it still wants to keep the same TURN session.
They introduce some new behavior and 3 new TURN attributes to achieve that
task.

On Fri, Nov 15, 2013 at 12:18 PM, Justin Uberti <[email-masked]> wrote:

>> MMUSIC has an interesting draft on TURN mobility (MICE) that I am
>> watching and I am going to implement. I wonder whether the authors of the
>> draft may be interested in the TURN evolution.
>>
>>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 15 Nov 2013 12:23:27 -0800

... since TURN binds the session to the 5-tuple. makes sense.

On Fri, Nov 15, 2013 at 12:21 PM, Oleg Moskalenko <[email-masked]>wrote:

> On Fri, Nov 15, 2013 at 12:18 PM, Justin Uberti <[email-masked]>wrote:
>
>>>> A few of us have been working on a proposal for a new working group
>>>> that would focus on enhancements to STUN and TURN. The proposed name is
>>>> TRAM (Turn Revised And Modernized) and discussion is happening in <
>>>> [email-masked]>.

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 15 Nov 2013 12:28:57 -0800

Yes, that would be an extension to the TURN that allows "session stealing".
I went through their draft, it looks reasonable and implementable, and I am
sure that it is useful for mobile devices. The security section of their
draft sounds reasonable, too:

http://tools.ietf.org/id/draft-wing-mmusic-ice-mobility-05.html

On Fri, Nov 15, 2013 at 12:23 PM, Justin Uberti <[email-masked]> wrote:

>> MICE may be interesting for WebRTC on mobile devices. It allows a
>> "mobile" TURN client: when a mobile device is moving from tower to tower,
>> it may change its IP address; but it still wants to keep the same TURN
>> session. They introduce some new behavior and 3 new TURN attributes to
>> achieve that task.
>>
>>

---

From: Dan Wing <[email-masked]>
Date: Fri, 15 Nov 2013 12:33:06 -0800

On Nov 15, 2013, at 12:21 PM, Oleg Moskalenko <[email-masked]> wrote:

> MICE may be interesting for WebRTC on mobile devices. It allows a "mobile" TURN client: when a mobile device is moving from tower to tower, it may change its IP address; but it still wants to keep the same TURN session. They introduce some new behavior and 3 new TURN attributes to achieve that task. 

(for others)  Those new TURN attributes for MICE effectively do the same as the HMAC in MPTCP's JOIN (RFC6824) and the similar function in SCTP (RFC4895 / RFC5061).

-d

> On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko <[email-masked]> wrote:
> MMUSIC has an interesting draft on TURN mobility (MICE) that I am watching and I am going to implement. I wonder whether the authors of the draft may be interested in the TURN evolution.
> 
> 
> On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault <[email-masked]> wrote:
> All,
>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 15 Nov 2013 21:43:26 +0000

Hi Paul - 

On Nov 15, 2013, at 2:44 PM, Paul Kyzivat <[email-masked]> wrote:

> I understand your concern. And it seems the controversial element has been removed from the charter/milestones.

First, let me admit that I didn't look to see if it was taken off the latest version of the charter proposal :-( 
I (blindly) assumed that it was still on there based on the fact that I didn't think we had reached consensus. I'm happy to see it settled as it is now.

> Are you suggesting that the TURN over websockets discussion happen on the TRAM list, but without a milestone? Or are you suggesting that the discussion needs to happen somewhere else?

I view the TRAM list strictly as a pre-WG list. For the sake of efficiency, IMO we should aim to try and limit discussions to progressing the formation of said WG. The technical discussions around TURNoWS are clearly lightning rods, so I think it is distracting to have them on the TRAM list. That said, I think it is fine to have discussions on the TRAM list related to finding a home for those technical discussions of TURNoWS to take place.

Cheers,

Gonzalo

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 16 Nov 2013 03:20:29 +0000

Hi Oleg,

I am co-author of the MICE, draft-reddy-behave-turn-auth drafts and we are interested in TURN evolution. Justin and we are working on TURN Extension for Third Party Authorization using OAuth which will address some of the problems discussed in above draft.

Cheers,
-Tiru.

From: Oleg Moskalenko <[email-masked]>
Subject: Re: [tram] First post
Date: November 15, 2013 11:01:24 AM PST
To: Simon Perreault <[email-masked]>
Cc: <[email-masked]>

Simon

====================

All,

Simon (and many others!)

  Candidate draft: TBD

- STUN-bis

  Candidate draft: TBD

  - Various bug fixes

- TURN-bis

  Candidate draft: TBD

  - Various bug fixes

Goals and Milestones:

[TBD]

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 15 Nov 2013 20:56:01 -0800

I reviewed the TURN part of the MICE and it looks promising. I am going to
add it as an experimental extension to our TURN server implementation.

The authorization work is very interesting, too.

Regards,
Oleg

On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> Hi Oleg,
>
> I am co-author of the MICE, draft-reddy-behave-turn-auth drafts and we are
> interested in TURN evolution. Justin and we are working on TURN Extension
> for Third Party Authorization using OAuth which will address some of the
> problems discussed in above draft.
>
> Cheers,
> -Tiru.
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 15 Nov 2013 23:26:09 -0800

Tiru, I suppose that will be similar to this draft:

http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-01

That would be a significant addition to the TURN server.

Regards,
Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 17 Nov 2013 13:36:41 +0000

Hi Oleg,

It has some similarities but is a lot different from PCP third party authorization. For example for TURN the Authorization Server will be providing session key, MAC algorithm etc which is not required with the PCP third party authorization.  There are various other differences like PCP server would need to communicate with the Authorization Server to determine the token bound authorization data  (like the number of mappings permitted, flow characteristics allowed etc) which may not be required with TURN authorization.  PCP-controlled Firewall will most likely be in the same administrative domain as the endpoint but that may not be true with TURN.

we are working on the the details and will have something concrete in couple of weeks.

Cheers,
-Tiru.
From: [email-masked] [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Saturday, November 16, 2013 12:56 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; [email-masked]; Justin Uberti
Subject: Re: [tram] First post

On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Oleg,

Cheers,
-Tiru.

From: Oleg Moskalenko <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] First post
Date: November 15, 2013 11:01:24 AM PST
To: Simon Perreault <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>

On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:
All,

Simon

====================

All,

A few of us have been working on a proposal for a new working group that would focus on enhancements to STUN and TURN. The proposed name is TRAM (Turn Revised And Modernized) and discussion is happening in <[email-masked]<mailto:[email-masked]>>.
Subscribe link: <https://www.ietf.org/mailman/listinfo/tram>

Simon (and many others!)

  Candidate draft: TBD

- STUN-bis

  Candidate draft: TBD

  - Various bug fixes

- TURN-bis

  Candidate draft: TBD

  - Various bug fixes

Goals and Milestones:

[TBD]

[email-masked]<mailto:[email-masked]>

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 17 Nov 2013 22:48:30 -0800

Dan and Tiru,

while contemplating the MICE implementation, I stumbled upon a potential
problem in the MICE draft.

According to the section 5.2.2, the server compares the encoded NONCE with
the stored NONCE for the "old" 5-tuple session. But the problem is, a NONCE
may expire. Its possible to have an expiration time for the NONCE (an
enhanced security feature). In a non-mobility TURN implementation, that
creates no problem: the server simple sends 438 error (stale nonce) back to
the client together with the new generated NONCE value, and the client just
re-calculates and re-sends the request.

With wording in the section 5.2.2, that becomes rather complicated in the
mobility case. I am not sure that I understand the exact action sequence
when the session NONCE expires with mobility feature.

I think that the problem can be fixed if the draft would not include
wording about the MOBILE-TICKET internal structure. In one place it is
saying that the ticket is opaque and implementation-dependent; but in other
places it suggests how the ticket must be constructed and how it must be
encoded. I think that this is unnecessary. Let's just say that the ticket
is opaque and its structure has meaning only for the server - and that the
server uses it as a unique identifier.

I see no reason why the server must encode any meaningful information in
the ticket, like 5-tuple and NONCE. That's totally up to the server. The
server, for example, may just keep a hashtable with all that information
and the ticket may be just a random unique key in that table. As we are
using message integrity authentication anyway, and the ticket is
transferred openly over the Internet, the ticket does not create any new
level of defense. This is, basically, just a session ID - to match the
"old" session with the "new" session.

A similar approach is used in RFC 6062. They are solving a similar logical
task: they are matching a new client network endpoint with an existing TURN
session. They also are using a ticket, but they do not encode any
information in it - that is just an opaque unique string. For protection,
they also are validating the MESSAGE INTEGRITY. And they have no problem
with the NONCE expiration because there is no NONCE encoded in the ticket.

Let me know please what do you think about that.

Thanks
Oleg

On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  Hi Oleg,
>
>
>
> It has some similarities but is a lot different from PCP third party
> authorization. For example for TURN the Authorization Server will be
> providing session key, MAC algorithm etc which is not required with the PCP
> third party authorization.  There are various other differences like PCP
> server would need to communicate with the Authorization Server to determine
> the token bound authorization data  (like the number of mappings permitted,
> flow characteristics allowed etc) which may not be required with TURN
> authorization.  PCP-controlled Firewall will most likely be in the same
> administrative domain as the endpoint but that may not be true with TURN.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Oleg Moskalenko
> *Sent:* Saturday, November 16, 2013 12:56 PM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Simon Perreault; [email-masked]; Justin Uberti
>
> *Subject:* Re: [tram] First post
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Nov 2013 06:59:08 -0800

> I view the TRAM list strictly as a pre-WG list. For the sake of efficiency, IMO we should aim to try and limit discussions to progressing the formation of said WG. The technical discussions around…

I have repeatedly asked *where* we could have that discussion in a way 
that satisfies those who are concerned. If we can't have it on TRAM, 
then were else?

Or are you suggesting that we should not have that discussion at all 
right now? (Rather wait for a WG to be chartered, and *then* have the 
discussion.)

	Thanks,
	Paul

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Nov 2013 11:09:20 -0500

> I (blindly) assumed that it was still on there based on the fact that I didn't think we had reached consensus. I'm happy to see it settled as it is now.

As a reminder, the latest version of the proposed charter is always 
available here:

https://github.com/petithug/tram-charter/blob/master/charter.txt

> I view the TRAM list strictly as a pre-WG list.

For now, yes. But I hope it becomes a WG list soon! :)

Simon

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 19 Nov 2013 00:28:12 +0000

On Nov 18, 2013, at 6:59 AM, Paul Kyzivat <[email-masked]> wrote:

> I have repeatedly asked *where* we could have that discussion in a way that satisfies those who are concerned. If we can't have it on TRAM, then were else?

I feel your pain and agree we need to figure out where.  I simply think that discussion would entirely consume and eventually fracture this group and would consequently delay formation of a WG to do all this this other work. I'm trying to be practical here and ensure *something* gets done in a timely fashion.
> 
> Or are you suggesting that we should not have that discussion at all right now? (Rather wait for a WG to be chartered, and *then* have the discussion.)

Yeah, this is where I'm going.

Gonzalo

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 19 Nov 2013 12:26:34 +0000

Hi Oleg,

Please see inline [TR]

From: [email-masked] [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Monday, November 18, 2013 12:19 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; [email-masked]; [email-masked]; Justin Uberti
Subject: Re: [tram] First post

Dan and Tiru,
while contemplating the MICE implementation, I stumbled upon a potential problem in the MICE draft.
According to the section 5.2.2, the server compares the encoded NONCE with the stored NONCE for the "old" 5-tuple session. But the problem is, a NONCE may expire. Its possible to have an expiration time for the NONCE (an enhanced security feature). In a non-mobility TURN implementation, that creates no problem: the server simple sends 438 error (stale nonce) back to the client together with the new generated NONCE value, and the client just re-calculates and re-sends the request.
With wording in the section 5.2.2, that becomes rather complicated in the mobility case. I am not sure that I understand the exact action sequence when the session NONCE expires with mobility feature.
I think that the problem can be fixed if the draft would not include wording about the MOBILE-TICKET internal structure. In one place it is saying that the ticket is opaque and implementation-dependent; but in other places it suggests how the ticket must be constructed and how it must be encoded. I think that this is unnecessary. Let's just say that the ticket is opaque and its structure has meaning only for the server - and that the server uses it as a unique identifier.
I see no reason why the server must encode any meaningful information in the ticket, like 5-tuple and NONCE. That's totally up to the server. The server, for example, may just keep a hashtable with all that information and the ticket may be just a random unique key in that table. As we are using message integrity authentication anyway, and the ticket is transferred openly over the Internet, the ticket does not create any new level of defense. This is, basically, just a session ID - to match the "old" session with the "new" session.

[TR] Agreed with your assessment will update the draft accordingly.

Thanks and Regards,
-Tiru.

A similar approach is used in RFC 6062. They are solving a similar logical task: they are matching a new client network endpoint with an existing TURN session. They also are using a ticket, but they do not encode any information in it - that is just an opaque unique string. For protection, they also are validating the MESSAGE INTEGRITY. And they have no problem with the NONCE expiration because there is no NONCE encoded in the ticket.

Thanks
Oleg

On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
Hi Oleg,

we are working on the details and will have something concrete in couple of weeks.
 
Cheers,
-Tiru.

On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
Hi Oleg,

Cheers,
-Tiru.

Simon

====================

All,

Simon (and many others!)

  Candidate draft: TBD

- STUN-bis

  Candidate draft: TBD

  - Various bug fixes

- TURN-bis

  Candidate draft: TBD

  - Various bug fixes

Goals and Milestones:

[TBD]

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 19 Nov 2013 10:15:47 -0800

That's great. I ll provide a sort of proof-of-concept reference impl soon.

Thanks
Oleg

Sent from my iPhone

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 20 Nov 2013 04:55:13 +0000

Changing the subject line.

Gonzalo, I was confused by your responses below.

On one hand you seem to be indicated that a discussion on TURNoWs, and presumable the other alternatives for handling TURN/RTP in the presence of HTTP Proxies, should not take place on this list and on the other you seem to indicate that the discussion could take place but has to wait until the WG has been chartered.

I cannot see any reason for delaying a discussion that we need to have to some future date so since it seem to have been decided to not have that discussion on this list then let's use the PNTAW list which was created for that purpose. 

Regards
Andy

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Gonzalo
> Salgueiro (gsalguei)
> Sent: 18 November 2013 16:28
> To: Paul Kyzivat
> Cc: [email-masked]
> Importance: High
> >>>> My main concern is that we have some element of agility with this
> work. The discussion over the past few days seem to indicate that we
> have a bunch of work that is not at all contentious and viewed as
> valuable by all. This work would likely get us a (BOF-less) WG stood up
> quickly and we have work in progress to address many of those
> milestones already. I just want to ensure we get all this work rolling
> along, rather than making WG formation dependent on issues known to be
> more contentious, requiring far more discussion and having many more
> dependencies on many different groups (i.e., HTTP traversal).  To be
> clear, I'm not saying lets not discuss these thing. I absolutely think
> they are important problems that need solving, but I think those
> discussions can happen in parallel and it would be highly inefficient
> to hold up all this other work on account of those interminable
> discussions.
> >>>
> >>> I understand your concern. And it seems the controversial element
> has been removed from the charter/milestones.
> >>
> >> First, let me admit that I didn't look to see if it was taken off
> the latest version of the charter proposal :-(
> >> I (blindly) assumed that it was still on there based on the fact
> that I didn't think we had reached consensus. I'm happy to see it
> settled as it is now.
> >>
> >>> Are you suggesting that the TURN over websockets discussion happen
> on the TRAM list, but without a milestone? Or are you suggesting that
> the discussion needs to happen somewhere else?
> >>
> >> I view the TRAM list strictly as a pre-WG list. For the sake of
> efficiency, IMO we should aim to try and limit discussions to
> progressing the formation of said WG. The technical discussions around
> TURNoWS are clearly lightning rods, so I think it is distracting to
> have them on the TRAM list. That said, I think it is fine to have
> discussions on the TRAM list related to finding a home for those
> technical discussions of TURNoWS to take place.
> >
> > I have repeatedly asked *where* we could have that discussion in a
> way that satisfies those who are concerned. If we can't have it on
> TRAM, then were else?
> 
> I feel your pain and agree we need to figure out where.  I simply think
> that discussion would entirely consume and eventually fracture this
> group and would consequently delay formation of a WG to do all this
> this other work. I'm trying to be practical here and ensure *something*
> gets done in a timely fashion.
> >
> >>>>> A few of us have been working on a proposal for a new working
> group that would focus on enhancements to STUN and TURN. The proposed
> name is TRAM (Turn Revised And Modernized) and discussion is happening
> in <[email-masked]>.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 20 Nov 2013 08:05:36 +0000

Andy - 

> I cannot see any reason for delaying a discussion that we need to have to some future date so since it seem to have been decided to not have that discussion on this list then let's use the PNTAW li…

We have clearly established that this discussion is controversial and there have been explicit statements indicating that if this work is bundled with the other (less contentious) work for this proposed WG, then formation of said WG would be blocked.  Thus, I think it is counterproductive to have those discussions and hold up all this other work.  I think we have the opportunity to quickly set up a WG (perhaps even without a BoF) if we limit the scope to the other proposed work items. I think the TURNoWS discussion MUST take place, but not at the expense of this other work.  I'm simply proposing we focus the discussions on tram@ to getting this WG formed with these other milestones and that it would be most efficient to temporarily limit the scope (on tram@) to finding the right place to have these much needed discussions.  Just my opinion...

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Nov 2013 16:35:54 -0800

> I cannot see any reason for delaying a discussion that we need to have to some future date so since it seem to have been decided to not have that discussion on this list then let's use the PNTAW li…

There seems to be some threat or fear of violating political correctness 
or "that which shall not be spoken" going on here. (Or maybe I am being 
paranoid and it is really just a concern about rat-hole'ing.)

I am just looking for some guidance on what forum to use for that 
discussion. I'm happy to have it on the the TRAM list, or the PNTAW 
list, or some other list. But when we have it, I don't want to later be 
told to start again because we chose the wrong list. I'd rather *not* 
have it on the RTCWEB list.

	Thanks,
	Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 21 Nov 2013 01:06:19 +0000

On Nov 20, 2013, at 4:35 PM, Paul Kyzivat <[email-masked]> wrote:

> There seems to be some threat or fear of violating political correctness or "that which shall not be spoken" going on here. (Or maybe I am being paranoid and it is really just a concern about rat-hole'ing.)

I'm gonna go with paranoid as I can assure you I have little care for political correctness.  I'm simply trying to advance the work with some measure of efficiency and avoid (for once) these toxic IETF delays.  All the while belaboring this point nine times further proves my point.
> 
> I am just looking for some guidance on what forum to use for that discussion. I'm happy to have it on the the TRAM list, or the PNTAW list, or some other list. But when we have it, I don't want to later be told to start again because we chose the wrong list. I'd rather *not* have it on the RTCWEB list.

I hear ya....I said let's discuss where it should happen.

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Nov 2013 21:10:45 -0800

> I'm gonna go with paranoid as I can assure you I have little care for political correctness.  I'm simply trying to advance the work with some measure of efficiency and avoid (for once) these toxic…

I didn't really have you in mind.
It's what you are reacting to.