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

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

On Mon, Jun 4, 2018 at 4:28 AM Sean Turner <sean@sn3rd.com> wrote:

> 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 <nohlmeier@mozilla.com> wrote:
> >
> > I reviewed the diff and I think it helps to clarify this.
> >
> > Best
> >   Nils
> >
> >> On Jun 3, 2018, at 20:48, Justin Uberti <juberti=
> 40google.com@dmarc.ietf.org> 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.
> >>
> >> 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 <fluffy@iii.ca> wrote:
> >>
> >>
> >>> On May 11, 2018, at 11:08 AM, Justin Uberti <juberti=
> 40google..com@dmarc.ietf.org> 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
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>