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

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?

On Fri, May 4, 2018 at 9:50 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

> Created https://github.com/juberti/draughts/pull/101
>
>   Nils
>
> On May 4, 2018, at 08:26, Sean Turner <sean@sn3rd.com> wrote:
>
> Repo is here :)
>
> https://github.com/juberti/draughts
>
> spt
>
> On May 1, 2018, at 17:33, Justin Uberti <juberti=
> 40google.com@dmarc.ietf.org> wrote:
>
> Do you want to take a shot at the text? (either in email or as a PR)
>
> On Mon, Apr 30, 2018 at 3:21 PM Nils Ohlmeier <nohlmeier@mozilla.com>
> wrote:
>
> On Apr 30, 2018, at 15:03, Justin Uberti <juberti@google.com> wrote:
>
> Any TURN server provided by the browser is in effect a proxy, and forcing
> use of said proxy can be done either through firewall config or explicit
> selection of Mode 4. (IOW, no new mode is needed.)
>
>
> I do agree that these two configurations result in a similar behavior.
> But I doubt that these use the same code path in implementations.
> And (thus) I doubt readers of the draft/RFC will automatically come to the
> same conclusion.
>
> It think it might be helpful to add another sentence explaining this
> scenario.
>
> The document originally pointed at RETURN as an example of how such TURN
> proxying could work, but was removed in order to avoid a dependency.
>
>
> Fair enough.
>
>  Nils
>
> On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings <fluffy@iii.ca> wrote:
>
>
> On Apr 17, 2018, at 3:15 AM, Justin Uberti <juberti=
> 40google.com@dmarc.ietf.org> wrote:
>
> IMO "trusting the TURN relay but not the application" is not a significant
> enough benefit to merit adding specific functionality for.
>
>
> In the case were the TURN server is provided by the JS, I agree. But in
> the case where the configuration of the browser provided the TURN server,
> then I think it is as trusted as say a VPN server.
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>