Subject: Re: [rtcweb] Nils comments [Was: WGLC for draft-ietf-rtcweb-ip-handling]

From: Justin Uberti <[email-masked]>
Date: Sun, 3 Jun 2018 20:48:34 -0700

Agreed. Created https://github.com/juberti/draughts/pull/102 that adds a
high-level discussion of enterprise TURN servers, hopefully enough to
clarify the situation.

If you think "browser-provided TURN server" is a clearer term, I could use
that instead.

On Mon, May 14, 2018 at 6:21 AM Cullen Jennings <[email-masked]> wrote:

>
>
> On May 11, 2018, at 11:08 AM, Justin Uberti <
> juberti=[email-masked]> wrote:
>
> Thanks for the PR. I spent some time thinking about this and ultimately
> concluded that more significant changes to the document will be necessary
> if it is to prescribe how a browser-provided TURN server should be handled,
> essentially incorporating much of the guidance from
> https://tools.ietf.org/html/draft-ietf-rtcweb-return-02
>
> For example, candidates produced from the TURN server should not have
> raddr/rport set; interactions between the browser-provided and any
> application-provided TURN server need to be described; the question of
> whether local candidates should be provided needs to be considered.
>
> As such, I see 3 paths forward here:
> a) Leave the document as-is. While leaving some ambiguity on this topic,
> the eventual (hopefully) publication of RETURN should clarify things, at
> which point we can publish a -bis.
> b) Discuss the general concept of browser-provided TURN servers, but
> mention that this is an area of further study, and give some guidance based
> on our current understanding. That is, explain how the existing modes would
> work in the presence of a browser-provided TURN server.
> c) Restore the reference to RETURN and progress the RETURN doc.
>
> Overall, I don't expect the mode recommendations to change in the presence
> of a browser- or network- provided TURN server, so I think any changes here
> will be almost entirely additive.
>
> Thoughts?
>
>
>
> I lean towards option B as it sounds like it meets our current needs and
> allows us to separate out the harder stuff to do later.
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Sun, 3 Jun 2018 21:11:53 -0700

I reviewed the diff and I think it helps to clarify this.

Best
  Nils

> On Jun 3, 2018, at 20:48, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Agreed. Created https://github.com/juberti/draughts/pull/102 <https://github.com/juberti/draughts/pull/102> that adds a high-level discussion of enterprise TURN servers, hopefully enough to clarify the situation.
> 
> If you think "browser-provided TURN server" is a clearer term, I could use that instead.
> 
> 
> 
> On Mon, May 14, 2018 at 6:21 AM Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On May 11, 2018, at 11:08 AM, Justin Uberti <juberti=[email-masked] <mailto:juberti=[email-masked]>> wrote:
>> 
>> Thanks for the PR. I spent some time thinking about this and ultimately concluded that more significant changes to the document will be necessary if it is to prescribe how a browser-provided TURN server should be handled, essentially incorporating much of the guidance from https://tools.ietf.org/html/draft-ietf-rtcweb-return-02 <https://tools.ietf.org/html/draft-ietf-rtcweb-return-02>
>> 
>> For example, candidates produced from the TURN server should not have raddr/rport set; interactions between the browser-provided and any application-provided TURN server need to be described; the question of whether local candidates should be provided needs to be considered.
>> 
>> a) Leave the document as-is. While leaving some ambiguity on this topic, the eventual (hopefully) publication of RETURN should clarify things, at which point we can publish a -bis.
>> b) Discuss the general concept of browser-provided TURN servers, but mention that this is an area of further study, and give some guidance based on our current understanding. That is, explain how the existing modes would work in the presence of a browser-provided TURN server.
>> Overall, I don't expect the mode recommendations to change in the presence of a browser- or network- provided TURN server, so I think any changes here will be almost entirely additive.
>> 
>> Thoughts?
> 
> 
> I lean towards option B as it sounds like it meets our current needs and allows us to separate out the harder stuff to do later. 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Sean Turner <[email-masked]>
Date: Mon, 4 Jun 2018 13:28:22 +0200

Let’s let this simmer until June 11th, but then we ought to merge it.

spt

> On Jun 4, 2018, at 06:11, Nils Ohlmeier <[email-masked]> wrote:
> 
>> Agreed. Created https://github.com/juberti/draughts/pull/102 that adds a high-level discussion of enterprise TURN servers, hopefully enough to clarify the situation.
>> 
>>> On May 11, 2018, at 11:08 AM, Justin Uberti <juberti=[email-masked]> wrote:
>>> 
>>> Thanks for the PR. I spent some time thinking about this and ultimately concluded that more significant changes to the document will be necessary if it is to prescribe how a browser-provided TURN server should be handled, essentially incorporating much of the guidance from https://tools.ietf.org/html/draft-ietf-rtcweb-return-02
>>>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Jun 2018 10:32:47 -0700

Assuming no further comments, will land this today and publish a new
version.

On Mon, Jun 4, 2018 at 4:28 AM Sean Turner <[email-masked]> wrote:

> >> Agreed. Created https://github.com/juberti/draughts/pull/102 that adds
> a high-level discussion of enterprise TURN servers, hopefully enough to
> clarify the situation.
> >>
> >>> Thanks for the PR. I spent some time thinking about this and
> ultimately concluded that more significant changes to the document will be
> necessary if it is to prescribe how a browser-provided TURN server should
> be handled, essentially incorporating much of the guidance from
> >>> a) Leave the document as-is. While leaving some ambiguity on this
> topic, the eventual (hopefully) publication of RETURN should clarify
> things, at which point we can publish a -bis.
> >>> Overall, I don't expect the mode recommendations to change in the
> presence of a browser- or network- provided TURN server, so I think any
> changes here will be almost entirely additive.
> >>>
> >>> Thoughts?
> >>
> >>
> >> I lean towards option B as it sounds like it meets our current needs
> and allows us to separate out the harder stuff to do later.
> >>
> >>