Re: [tram] TURN/RTP via HTTP Proxy

[Paul Kyzivat <[e-mail]>]

On 11/19/13 8:55 PM, Hutton, Andrew wrote:
> 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.

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

> Regards
> Andy
>
>
>
>
>> -----Original Message-----
>> From: tram [mailto:[e-mail]] On Behalf Of Gonzalo
>> Salgueiro (gsalguei)
>> Sent: 18 November 2013 16:28
>> To: Paul Kyzivat
>> Cc: [e-mail]
>> Subject: Re: [tram] First post
>> Importance: High
>>
>>
>> On Nov 18, 2013, at 6:59 AM, Paul Kyzivat <[e-mail]>
>> wrote:
>>
>>> On 11/15/13 1:43 PM, Gonzalo Salgueiro (gsalguei) wrote:
>>>> Hi Paul -
>>>>
>>>> On Nov 15, 2013, at 2:44 PM, Paul Kyzivat <[e-mail]>
>> wrote:
>>>>
>>>>> Gonzalo,
>>>>>
>>>>> On 11/15/13 11:20 AM, Gonzalo Salgueiro (gsalguei) wrote:
>>>>>> 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.
>>>>>
>>>>> 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.
>>>
>>> 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
>>
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>>
>>>>> 	Thanks,
>>>>> 	Paul
>>>>>
>>>>>> Gonzalo
>>>>>>
>>>>>> On Nov 15, 2013, at 1:55 PM, Simon Perreault
>> <[e-mail]> 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 <[e-mail]>.
>>>>>>> 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
>>>>>>> _______________________________________________
>>>>>>> tram mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/tram
>>>>>>
>>>>>> _______________________________________________
>>>>>> tram mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/tram
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tram mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tram
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> tram mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tram
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>