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

Cullen Jennings <fluffy@iii.ca> Mon, 14 May 2018 13:20 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F75212E043 for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2018 06:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk4z9ltP5W3G for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2018 06:20:50 -0700 (PDT)
Received: from smtp65.ord1d.emailsrvr.com (smtp65.ord1d.emailsrvr.com [184.106.54.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6881B124D6C for <rtcweb@ietf.org>; Mon, 14 May 2018 06:20:50 -0700 (PDT)
Received: from smtp1.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id B1F0240086; Mon, 14 May 2018 09:20:49 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp1.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5775E40078; Mon, 14 May 2018 09:20:49 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Mon, 14 May 2018 09:20:49 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_EA91D61B-245E-4E4A-AFFD-EAD6118739E1"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAOJ7v-3uxT2fZdxxcz93TsSMFHaJCOURZnv=_aNiYo-enS3D9g@mail.gmail.com>
Date: Mon, 14 May 2018 07:20:48 -0600
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, RTCWeb IETF <rtcweb@ietf.org>
Message-Id: <6DF5B202-803F-452B-B17E-5346F4C6FB4B@iii.ca>
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <F9EB7388-9E76-43E0-8C9B-61D3E50357F7@mozilla.com> <CAOJ7v-38kH4peZVVJU8itve2P+93eGaVdJ60MVcaRo3Xu86uTQ@mail.gmail.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> <CAOJ7v-3wBVdfacAvb=VOggMXWMD1-5Oq-GCb5cNSCy3_-ur3Gw@mail.gmail.com> <A58B5A3B-DF5E-484B-ADD5-EBA539D0F250@iii.ca> <CAOJ7v-3FbN7v00Lzc5kJV4Nsw5DD0c6zLDLY+x1AgSOEHSt_WA@mail.gmail.com> <D6DEE1F6-A105-4095-902D-CB6F5AA2D937@mozilla.com> <CAOJ7v-2aXsQrwJ77+MsZ0cw-cx=VJTccFJwc9rxSFjdd+bCs-g@mail.gmail.com> <0E876BDE-C438-43AD-B87A-95894ADCBF8F@sn3rd.com> <574256E1-7AF4-4E25-9462-04B4B599C801@mozilla.com> <CAOJ7v-3uxT2fZdxxcz93TsSMFHaJCOURZnv=_aNiYo-enS3D9g@mail.gmail.com>
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/mZx-j79gB-hWQXQH6MSW_o9LFnA>
Subject: Re: [rtcweb] Nils comments [Was: WGLC for draft-ietf-rtcweb-ip-handling]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 13:20:52 -0000


> 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 <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.