From nobody Sun Apr 1 04:32:47 2018 Return-Path: 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 6AFAF124207 for ; Sun, 1 Apr 2018 04:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 r2XzfEgUh04l for ; Sun, 1 Apr 2018 04:32:42 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) (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 DFC5112025C for ; Sun, 1 Apr 2018 04:32:41 -0700 (PDT) Received: (qmail 21863 invoked from network); 1 Apr 2018 11:32:39 -0000 X-APM-Authkey: 255286/0(159927/0) 100 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 1 Apr 2018 11:32:39 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id EFF7818A0E46 for ; Sun, 1 Apr 2018 12:32:38 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9O3xzzr159CJ for ; Sun, 1 Apr 2018 12:32:38 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id CA3C518A01CB for ; Sun, 1 Apr 2018 12:32:38 +0100 (BST) From: T H Panton Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 1 Apr 2018 12:32:37 +0100 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> To: RTCWeb IETF In-Reply-To: <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> Message-Id: <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 11:32:46 -0000 Concretely could we adjust : " Mode 1 MUST only be used when user consent has been provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent." to:=20 " Mode 1 MUST only be used when a user's informed consent has been = provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to one of the the existing = getUserMedia/location-access consents. Alternatively implementations can provide a separate mechanism to = obtain user consent" - I'm no GDPR specialist, but I think adding 'informed' above may be = wise. Likewise I believe even the non-normative language should be clearer = about the possible implementation choices. Tim. > On 1 Apr 2018, at 01:12, westhawk wrote: >=20 > GuM permission is the wrong trust measure here. >=20 > So for example, If I use webRTC to get a realtime feed from a webcam/ = baby monitor > then I won=E2=80=99t use GuM, all my recv_only video traffic will go = via a TURN server > even if I=E2=80=99m on the same Wifi ? >=20 > Likewise if I use webRTC DC to control my lighting, I get extra = latency because > I don=E2=80=99t need GuM? >=20 > (Both of these are real projects). >=20 > My current workaround is to use the camera to scan a QR and piggyback = off > that permission. (Which is crazy). >=20 > The IP address reveal is unrelated to the UserMedia. > It is a =E2=80=98Trust/location' issue. >=20 > Also - if GuM permission was granted for this origin, does this mean = that=20 > subsequent page loads that _don=E2=80=99t_ request GuM don=E2=80=99t = get local candidates > even if they would get GuM if they asked for it? > (i.e. if I=E2=80=99ve once scanned a QR on this domain, do I always = reveal my local/public IPs?) >=20 > Try explaining the logic of any of that to anyone outside this = group=E2=80=A6. >=20 > Tim. >=20 >> On 1 Apr 2018, at 00:47, Lennart Grahl = wrote: >>=20 >> On 01.04.2018 00:26, Justin Uberti wrote: >>> As stated before, this is not a problem unique to web browsers. That = is, by >>> installing a mobile application, you implicitly allow it to use all = of your >>> network interfaces. As such, trying to design browser mechanisms for >>> networking consent seems like misdirected effort. >>=20 >> First of all, that comparison doesn't really work for me since an app = is >> much less of a sandbox. So, I personally do not trust arbitrary = websites >> but I do trust apps that I install (or I just don't install them, or = I >> partially trust them and revoke some of the permissions they have). >>=20 >> It's all about expectations: WebRTC networking is special - it does >> networking entirely different to what people were accustomed to in >> browsers. Which is probably why people are so irritated when they = learn >> that it leaks IPs even though they've set a proxy or a VPN. And along >> with the argument that gUM just does not work for a bunch of use = cases, >> that is the rationale for my suggestion towards a networking = "consent" >> mechanism. With that mechanism in place the user has a voice, we = cover >> more use cases, browsers can ship stricter modes by default without >> breaking everything we love about peer-to-peer connections and = privacy >> extensions might consider dropping WebRTC from their blacklist. I >> honestly do not see this as being terribly misguided. >>=20 >>> Perhaps the key issue here is the word 'consent'. If we replaced = this with >>> some notion of 'trust', i.e., that the user has specifically engaged = with >>> this app with the intent of having a communications session, maybe = that >>> provides a way out, as one can easily claim that installed mobile >>> applications and web apps with gUM rights are 'trusted'. >>=20 >> I'm sorry but I don't really see the difference. gUM requests a >> permission to access your camera and your microphone and then assumes >> you're "trusting" the page for something different as well. >>=20 >>>=20 >>> On Sat, Mar 31, 2018 at 3:18 AM Lennart Grahl = >>> wrote: >>>=20 >>>> I really don't have a good suggestion other than being completely >>>> honest: "Hey user, I want to establish a direct connection - is = that >>>> okay for you? Oh, and here is a help page that will tell you what = impact >>>> this may have on your privacy..." >>>>=20 >>>> These permission requests don't have to be mutually exclusive = either. >>>> The above request could also be embedded inside the permission = request >>>> for getUserMedia to avoid multiple requests: >>>>=20 >>>> Camera to share: >>>> [WebCam 3000 |v] >>>> :WebCam 3000 : >>>> :WebCam 4000 : >>>>=20 >>>> Direct connection: (?) <-- "help" button >>>> [No (Default) |v] >>>> :Yes : >>>> :Yes, but hide private addresses : >>>> :No (Default) : >>>> :No, and force using a proxy : >>>>=20 >>>> [x] Remember the decision for this page >>>>=20 >>>> [Don't allow] [Allow] >>>>=20 >>>> Cheers >>>> Lennart >>>>=20 >>>> On 31.03.2018 00:12, Sean Turner wrote: >>>>>=20 >>>>>=20 >>>>>> On Mar 29, 2018, at 23:48, Lennart Grahl = >>>> wrote: >>>>>>=20 >>>>>> I'm fine with the modes, I don't have a strong opinion on whether = or not >>>>>> an IETF document should include some form of "consent". But I do = have a >>>>>> problem with the suggestion to use getUserMedia. Can we maybe = remove it? >>>>>=20 >>>>> As the draft shepherd, I=E2=80=99m trying to figure out how to = draw this WGLC to >>>> a close all in the hopes that we can help each other get this = RTCweb WG >>>> ship docked. >>>>>=20 >>>>> As far as dropping the getUserMedia suggestion, I=E2=80=99m a = little hesitant to >>>> just drop it at this late date. That suggestion has been in the = draft >>>> since October 2016 and it=E2=80=99s stood the test of a couple of = WG reviews; not >>>> last calls mind you but there=E2=80=99s been plenty of time for = folks to say get >>>> that outta there. And technically, it=E2=80=99s just a suggestion = with no >>>> normative language. So =E2=80=A6 maybe a happy middle ground is to = have another >>>> suggestion so that there=E2=80=99s more than one potential = mechanism? >>>>>=20 >>>>> spt >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Apr 1 04:51:23 2018 Return-Path: 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 BF72C120724 for ; Sun, 1 Apr 2018 04:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 4ybBjbherUX6 for ; Sun, 1 Apr 2018 04:51:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5768C12025C for ; Sun, 1 Apr 2018 04:51:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1BF7CBE51; Sun, 1 Apr 2018 12:51:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoYQEm4EojpR; Sun, 1 Apr 2018 12:51:16 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DEE83BE50; Sun, 1 Apr 2018 12:51:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1522583476; bh=01tedX7i/aicTAo8/iHSeW5wOKBcTBpqIdNogWnmVOI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=tlVjkw/8RWB9H3iLVIj+WT3nKNJn3BTjpP1Ke+XI/hDCwZZEuQ/dVgnUs1NEpXDzl z30RNADIuMRvStgkfJC589hPk86Srpyg1D26QB1QWTxUVWWj6P+AZZ625XerynaWT2 J4IOOAv7AcQzg/rfBFJvIAYiGxi11PgGSVnkm6Hs= To: T H Panton , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> Date: Sun, 1 Apr 2018 12:51:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oFgwhOu8zqc0LZH1gO4agRYj9qmblwvAM" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 11:51:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oFgwhOu8zqc0LZH1gO4agRYj9qmblwvAM Content-Type: multipart/mixed; boundary="s5AfpfTkxcRm45xI5yw4ZveiKTNu3TtCG"; protected-headers="v1" From: Stephen Farrell To: T H Panton , RTCWeb IETF Message-ID: <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> In-Reply-To: <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> --s5AfpfTkxcRm45xI5yw4ZveiKTNu3TtCG Content-Type: multipart/mixed; boundary="------------58CC28651C82E101EE9F133E" Content-Language: en-GB This is a multi-part message in MIME format. --------------58CC28651C82E101EE9F133E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/04/18 12:32, T H Panton wrote: > - I'm no GDPR specialist, but I think adding 'informed' above may be wi= se. Luckily, I'm also not a GDPR specialist:-) But I think adding "informed" takes this further from reality and so is worse. (Further from reality in terms of me just not believing that ICE is understandable for a random user, and therefore consent of any kind to doing iCE, isn't possible, so informed consent is even less possible;-) In general I'm not sure wordsmithing will help here - I reckon those of us in the rough (well, me at least), have a fundamental problem with the current state of implementations and with the basic idea in the draft so I don't think any simple wording change can solve that. (I'm not saying that to be difficult but to avoid us all wasting time thinking we can solve the problems via wordsmithing.) Cheers, S. --------------58CC28651C82E101EE9F133E Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------58CC28651C82E101EE9F133E-- --s5AfpfTkxcRm45xI5yw4ZveiKTNu3TtCG-- --oFgwhOu8zqc0LZH1gO4agRYj9qmblwvAM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJawMezAAoJEFqy+vF7FyvqIwYP/1ebc31L7KF7a2MS95nbVjQs yRI5K9hns/vBQi59OT8pDVhXXfc8CHNhDB91su8/mZTviRcj2Sc0ZMUad/AVyWuf avwYNv9GTIfftdrY2TtK6uqs313kYMuY4qS+QZiQVrA1BCO+LozyvLmTi0McfFch fh5zvIT0t7z0+hvlLcP1w/0doHDSkAGPvOeK93zDdEStGyoR0RiReHvQ6VeHdK41 pZexqFpzvF9CfGSKp5qP4CfrEDw/zECLxtmfTdbnbbaYPoTNiial8nhZ1kzioPij M+KfARxw7VlUNwJs798ryJTufBAr1tQXaqgDOoUr4ZNhB1/+VAKSjXujgk3dBI9s fE6rMCyNwHffhwCJsrDDHPvHvtIlQGWubXWfFyBHZP+wkryrFwiHh3kDln9RZyST 4r1UAshMGywVGtrsZy/u4By80AELsC22oB1QwZXoW26VD2cP97lx9diRJfKTfhun 6isV6dX6wGtTFaJ0C/gkTeUvLl13WNN3iewUap7j0QVMe6oA+6TdOkRox79SxTWe pmpsFxNXJ8MlEQpRmttWacwoREe2NvL90UIBxsFvV/yhol6z8gyqQo/S+4mhLnen HIGXR92z8AI5VUKk5XsAR3MnfKp9vJFfznJxEO2egz+VgV+3QKjPqTJX5ieB+tJ0 y56p+LIcn6NazshDW9RD =6dz4 -----END PGP SIGNATURE----- --oFgwhOu8zqc0LZH1gO4agRYj9qmblwvAM-- From nobody Sun Apr 1 05:51:35 2018 Return-Path: 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 2F1D4120724 for ; Sun, 1 Apr 2018 05:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 9KxQACYaOTPT for ; Sun, 1 Apr 2018 05:51:32 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 219661200E5 for ; Sun, 1 Apr 2018 05:51:31 -0700 (PDT) Received: (qmail 32680 invoked from network); 1 Apr 2018 12:51:29 -0000 X-APM-Authkey: 255286/0(159927/0) 114 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 1 Apr 2018 12:51:29 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id A552318A0B69; Sun, 1 Apr 2018 13:51:29 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YYDphn5iGzUh; Sun, 1 Apr 2018 13:51:29 +0100 (BST) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 81C9318A067F; Sun, 1 Apr 2018 13:51:29 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: westhawk In-Reply-To: <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> Date: Sun, 1 Apr 2018 13:51:28 +0100 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 12:51:34 -0000 > On 1 Apr 2018, at 12:51, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 01/04/18 12:32, T H Panton wrote: >> - I'm no GDPR specialist, but I think adding 'informed' above may be = wise. >=20 > Luckily, I'm also not a GDPR specialist:-) Giving literal consent is somewhat frowned on these days - hence = =E2=80=98informed'. >=20 > But I think adding "informed" takes this further from reality and so = is > worse. (Further from reality in terms of me just not believing that = ICE > is understandable for a random user, and therefore consent of any kind > to doing iCE, isn't possible, so informed consent is even less > possible;-) >=20 Ah, that=E2=80=99s where we disagree. We don=E2=80=99t have to explain = ICE - (frankly almost no-one understands ICE not even those of us who have implemented it.) Just like we don=E2=80=99t explain the detailed risks of giving camera = permissions. But I do think we can give a better hint at what the area of risk is, = fundamentally: "do you trust this website with your (network) location?=E2=80=9D Whilst some of the detailed risks are shared with =E2=80=9Cdo you want to use your camera?=E2=80=9D Not enough of them are = IMHO. > In general I'm not sure wordsmithing will help here - I reckon those = of > us in the rough (well, me at least), have a fundamental problem with > the current state of implementations and with the basic idea in the > draft so I don't think any simple wording change can solve that. (I'm > not saying that to be difficult but to avoid us all wasting time > thinking we can solve the problems via wordsmithing.) Mmm, I think we differ, I=E2=80=99d rather give wordsmithing a try = before we go back to square 1. T. >=20 > Cheers, > S. > <0x5AB2FAF17B172BEA.asc> From nobody Sun Apr 1 06:26:38 2018 Return-Path: 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 933D51241FC for ; Sun, 1 Apr 2018 06:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 9SvTbCWAPoSS for ; Sun, 1 Apr 2018 06:26:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B262120724 for ; Sun, 1 Apr 2018 06:26:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 803EEBE53; Sun, 1 Apr 2018 14:26:31 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtnGd_bjHKwN; Sun, 1 Apr 2018 14:26:30 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EDB00BE50; Sun, 1 Apr 2018 14:26:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1522589190; bh=IusRa/MycOlFWmy7wh3U5ONUhxuilmvA7OKsEPkVsmQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PZ/nslZBfYg4pmggxzrLLXXDQGQ+PCv+3hQa2FAaUsi9fYfJdbGn6iXZr7t+iOCXO b76jNwJC0XnooQX4mGWTG1WcelvKtmqSJr86L3wDffzd+CH99cpZQY/hTjPaDXOyJT KEBgGfhqfe+N2OYkKEJbRqpfivJofQtlv0Wi35Lk= To: westhawk Cc: RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> Date: Sun, 1 Apr 2018 14:26:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y3VTNAYykQMHO74x94h6PqHJ2NSDJyg6D" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 13:26:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --y3VTNAYykQMHO74x94h6PqHJ2NSDJyg6D Content-Type: multipart/mixed; boundary="C4DsnTjzEyNtHKIT2tjdOiiAIuZGFKFDW"; protected-headers="v1" From: Stephen Farrell To: westhawk Cc: RTCWeb IETF Message-ID: <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> In-Reply-To: <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> --C4DsnTjzEyNtHKIT2tjdOiiAIuZGFKFDW Content-Type: multipart/mixed; boundary="------------9C0414C09FF302A0A228A668" Content-Language: en-GB This is a multi-part message in MIME format. --------------9C0414C09FF302A0A228A668 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/04/18 13:51, westhawk wrote: > Giving literal consent is somewhat frowned on these days - hence =E2=80= =98informed'. This [1] captures my understanding of informed consent pretty well. In particular where it says: "An informed consent can be said to have been given based upon a clear appreciation and understanding of the facts, implications, and consequences of an action." That's the kind of definition we use when considering research ethics. It's unclear to me why some other definitions might apply in a case like WebRTC in browsers that will affect many many more people. Cheers, S. [1] https://en.wikipedia.org/wiki/Informed_consent --------------9C0414C09FF302A0A228A668 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------9C0414C09FF302A0A228A668-- --C4DsnTjzEyNtHKIT2tjdOiiAIuZGFKFDW-- --y3VTNAYykQMHO74x94h6PqHJ2NSDJyg6D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJawN4FAAoJEFqy+vF7FyvqLJoP/1oj7hx2ZiTBBmRJw7D2NNG8 MXP9dUS5t+dbLhYv1Nmfa7GAP36t2c2vJ+OJId94+NQC3NQYzzQLSwlbZ7oOn7K/ xcN8PWH9YJe6wnE+y7F5vwHR/I4dMMHSEPfzXXppX8VHn0oB1RAA6vP1sJ1lhAuB yOYgmLZIh+0UTpW9qwF+gtcVstX+HNiiSczwX8yTXusspcVULuWG1sbI8+wxWBF6 IPJeC/T3EsBImNDF0uKSiSbjX5K0uwND9hfILBTt/Ov9/AfQKEHnifsX0URPThN+ IgWJ3RxtpoqkpsOazEjxmUoxuG8Q06NvXIgXpTMf8ol90M25xg+6vg0ZBYci9bRC T8SCsFG/PIpSw7ilPlf9zxU+sCcNmlBuqdRaTBo9zDPqb0Wc6J9nZiNXl25cfQoA uPn10z5vieUn9mfaXJLIWBll3mSYzdw1mCcq+Ra/g5ztJFDGfdAHeCov/KJcfAN9 Y/CRSEmPmQrK3LZebgXQVHQSCnElkFiIYGAiK3iWLBqyAYibO0yhpNiydqk5xTPL c3T0EabS4d7en/wHTVu8S48G+1F1/t7eD6AVffjgPft9mnfPfQsmXNJ1UV1Avd7O ZKRRP1xK1f/2ZOsR6uO+GQFTK0dAB8kBU8OTcWFOllJ6nr3ryJk6QOSS2FZUjw9u 1BfV90ZtJ67hFdtxa8Iu =IzHv -----END PGP SIGNATURE----- --y3VTNAYykQMHO74x94h6PqHJ2NSDJyg6D-- From nobody Sun Apr 1 13:42:47 2018 Return-Path: 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 B1525124235 for ; Sun, 1 Apr 2018 13:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 x_Up0vUK9Ac1 for ; Sun, 1 Apr 2018 13:42:42 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66C91200A0 for ; Sun, 1 Apr 2018 13:42:42 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id y46-v6so13952539otd.4 for ; Sun, 01 Apr 2018 13:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ke+kotfGGDDEq2gFDlZDpbyS7y/ZPFZaYOqHbFpmE44=; b=0om2zXlpnYbqFpk+ew/Eu7X3J/Fi+bmnqKbVeZArsleyWBfL58T8Ms5wvTExGk8tff iD/YwnSH8PCfSimUm4p2sS1oUjVoNVYE8OzOUMtpmxSBWNboeKLhOKFa31VoHhny80eB 7GkyTHmAw3+MqLRHqzdzJol8azG1hhtSzTvi7Et1cUTCkgzMjI7s0Ysh1aV84N9LYEG0 qKtSEunJJVm6cE1S+PmI30olXp9qt26fU6vEvfP/HdQK3aJ2bQAoO+hOLQyFO+kSGlcc FXw85y9bTw0sPG9utENjq37GBW2P2JtNgx2vgqS4I8LvBI+uhfHUF47+vOftuQKDYSIs CGFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ke+kotfGGDDEq2gFDlZDpbyS7y/ZPFZaYOqHbFpmE44=; b=E+VWdEH9rVxMnPj9+9Xpr7s4ep/u0/AJdfwjaGbjsZb8uzfRJu3tFCBsIj6bs68qWf Ksg5V/JX1AOGBRKb8udfOcg6NC0D82IkxBo/d3dDl5dvgedz5nUoPTBsuw0ASsfEEF1h qN3rbXaXgy0275qzpUzJ1SCIJ1HpOB0T/6DFu/Gtz7aBFdXLSutp+EhqzSCDeXdR7857 vELtIDADxs/MfzYiCKYTX/4wW+W8IwiM9x77kpJIodb+znRYBHaaR9Zi5mqt1TBwjRhS V9MqoD4JWxZoaNRZZTvNTXiTzu2jGdn+ZwfbaXNQ0iFZ3I0zQh7ZeAEFHYd3IvqO2ZVF GK8g== X-Gm-Message-State: ALQs6tBy6vaIXHkT6b+TRf1R76F8r54RT1fd4uj3RgxEIPecc9QFDgXx Lxjn3V0/525UWaK0u5rrUEU3GPZZrzj01YgadnM9D2zz X-Google-Smtp-Source: AIpwx492n+gc2poHQEYqvq8dlMQehxm1cEwoJyDG8s71GgcSJkxKNGDo4UbE9MBlE75h7GGsA9QfXI5aADlNa5zCgQ8= X-Received: by 2002:a9d:3636:: with SMTP id w51-v6mr3287945otb.101.1522615361891; Sun, 01 Apr 2018 13:42:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Sun, 1 Apr 2018 13:42:01 -0700 (PDT) In-Reply-To: <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> From: Eric Rescorla Date: Sun, 1 Apr 2018 13:42:01 -0700 Message-ID: To: Stephen Farrell Cc: westhawk , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000c67f880568cf836b" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 20:42:46 -0000 --000000000000c67f880568cf836b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 1, 2018 at 6:26 AM, Stephen Farrell wrote: > > > On 01/04/18 13:51, westhawk wrote: > > Giving literal consent is somewhat frowned on these days - hence > =E2=80=98informed'. > > This [1] captures my understanding of informed consent pretty well. In > particular where it says: "An informed consent can be said to have been > given based upon a clear appreciation and understanding of the facts, > implications, and consequences of an action." > > That's the kind of definition we use when considering research ethics. > > It's unclear to me why some other definitions might apply in a case > like WebRTC in browsers that will affect many many more people. > This is the standard term of art. I believe we should leave it as-is -Ekr > Cheers, > S. > > [1] https://en.wikipedia.org/wiki/Informed_consent > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --000000000000c67f880568cf836b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 1, 2018 at 6:26 AM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:


On 01/04/18 13:51, westhawk wrote:
> Giving literal consent is somewhat frowned on these days - hence =E2= =80=98informed'.

This [1] captures my understanding of informed consent pretty well. = In
particular where it says: "An informed consent can be said to have bee= n
given based upon a clear appreciation and understanding of the facts,
implications, and consequences of an action."

That's the kind of definition we use when considering research ethics.<= br>
It's unclear to me why some other definitions might apply in a case
like WebRTC in browsers that will affect many many more people.

This is the standard term of art. I believe we sho= uld leave it as-is

-Ekr


Cheers,
S.

[1] https://en.wikipedia.org/wiki/Informed_consen= t

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--000000000000c67f880568cf836b-- From nobody Mon Apr 2 06:55:24 2018 Return-Path: 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 7CF0712785F for ; Mon, 2 Apr 2018 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 t-JUAhP8zeKW for ; Mon, 2 Apr 2018 06:55:21 -0700 (PDT) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (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 1DC4C126FB3 for ; Mon, 2 Apr 2018 06:55:21 -0700 (PDT) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3F46E552F; Mon, 2 Apr 2018 09:55:18 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BE061549E; Mon, 2 Apr 2018 09:55:17 -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:587 (trex/5.7.12); Mon, 02 Apr 2018 09:55:18 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Cullen Jennings In-Reply-To: Date: Mon, 2 Apr 2018 07:55:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <443FC3E5-891C-49BB-90A1-C3139D3C0655@iii.ca> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 13:55:22 -0000 All the stuff we are discussing here has been brought up and discussed = in the WG. If there was a way we could tweak the words of this to be = better, I think we would have already done that. What I don=E2=80=99t = want to do is spend a bunch of time rehash old arguments and several = months from now come to exactly where we are today. The wording has been = tweaked many times. The browsers added APIs so that browser extensions = could have better control over what happened. Thick apps have access to = all this same data.=20 I don=E2=80=99t agree with some parts of the draft but I do recognize = that the WG had consensus that the current document covers the issues = and I am just in the rough on this. I think most the WG feels that the = current draft is the best possible choice and the browser have done what = they can to mitigate this. That=E2=80=99s why I tried to make it clear = in my email that I don=E2=80=99t expect this draft to change because of = my concerns, but I am simply noting my disagreement. I do not think that = spending a bunch more time discussing this would in change the outcome = from what the draft currently says.=20 Cullen From nobody Tue Apr 3 02:14:33 2018 Return-Path: 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 34B581270A0 for ; Tue, 3 Apr 2018 02:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 nA60Wse-ifGF for ; Tue, 3 Apr 2018 02:14:29 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 5052A124205 for ; Tue, 3 Apr 2018 02:14:28 -0700 (PDT) Received: (qmail 96479 invoked from network); 3 Apr 2018 09:14:27 -0000 X-APM-Authkey: 255286/0(159927/0) 538 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 3 Apr 2018 09:14:27 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 11BF518A0D4B; Tue, 3 Apr 2018 10:14:27 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7BUu-sIQ9xed; Tue, 3 Apr 2018 10:14:26 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id DEF5B18A018E; Tue, 3 Apr 2018 10:14:26 +0100 (BST) From: T H Panton Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_06B506A8-B082-429F-BFF4-D2B3C172AF1C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 3 Apr 2018 10:14:26 +0100 In-Reply-To: <443FC3E5-891C-49BB-90A1-C3139D3C0655@iii.ca> Cc: RTCWeb IETF To: Cullen Jennings References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> <443FC3E5-891C-49BB-90A1-C3139D3C0655@iii.ca> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 09:14:32 -0000 --Apple-Mail=_06B506A8-B082-429F-BFF4-D2B3C172AF1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In case anyone thinks this issue will go away if we ignore it: = https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_l= eak_ip_addresses/ = T. > On 2 Apr 2018, at 14:55, Cullen Jennings wrote: >=20 >=20 > All the stuff we are discussing here has been brought up and discussed = in the WG. If there was a way we could tweak the words of this to be = better, I think we would have already done that. What I don=E2=80=99t = want to do is spend a bunch of time rehash old arguments and several = months from now come to exactly where we are today. The wording has been = tweaked many times. The browsers added APIs so that browser extensions = could have better control over what happened. Thick apps have access to = all this same data.=20 >=20 > I don=E2=80=99t agree with some parts of the draft but I do recognize = that the WG had consensus that the current document covers the issues = and I am just in the rough on this. I think most the WG feels that the = current draft is the best possible choice and the browser have done what = they can to mitigate this. That=E2=80=99s why I tried to make it clear = in my email that I don=E2=80=99t expect this draft to change because of = my concerns, but I am simply noting my disagreement. I do not think that = spending a bunch more time discussing this would in change the outcome = from what the draft currently says.=20 >=20 > Cullen >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_06B506A8-B082-429F-BFF4-D2B3C172AF1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = case anyone thinks this issue will go away if we ignore it:

https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vp= ns_tested_leak_ip_addresses/

T.


On 2 Apr 2018, at 14:55, Cullen Jennings <fluffy@iii.ca> = wrote:


All the stuff we are discussing here has been = brought up and discussed in the WG. If there was a way we could tweak = the words of this to be better, I think we would have already done that. = What I don=E2=80=99t want to do is spend a bunch of time rehash old = arguments and several months from now come to exactly where we are = today. The wording has been tweaked many times. The browsers added APIs = so that browser extensions could have better control over what happened. = Thick apps have access to all this same data.

I don=E2=80=99t agree with some parts of the draft but I do = recognize that the WG had consensus that the current document covers the = issues and I am just in the rough on this. I think most the WG feels = that the current draft is the best possible choice and the browser have = done what they can to mitigate this. That=E2=80=99s why I tried to make = it clear in my email that I don=E2=80=99t expect this draft to change = because of my concerns, but I am simply noting my disagreement. I do not = think that spending a bunch more time discussing this would in change = the outcome from what the draft currently says.

Cullen

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_06B506A8-B082-429F-BFF4-D2B3C172AF1C-- From nobody Tue Apr 3 06:17:41 2018 Return-Path: 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 E6FB012778D for ; Tue, 3 Apr 2018 06:17:39 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZaiWelg1pSSO for ; Tue, 3 Apr 2018 06:17:36 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB9E12025C for ; Tue, 3 Apr 2018 06:17:36 -0700 (PDT) Received: from [192.168.1.230] ([84.20.98.117]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id w33DHd5L011295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 3 Apr 2018 15:17:41 +0200 To: rtcweb@ietf.org References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> <443FC3E5-891C-49BB-90A1-C3139D3C0655@iii.ca> From: Philipp Hancke Message-ID: Date: Tue, 3 Apr 2018 15:17:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 13:17:40 -0000 Am 03.04.2018 um 11:14 schrieb T H Panton: > In case anyone thinks this issue will go away if we ignore it: > > https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/ It turned out the issue in this case is a) browser extensions that add a proxy server calling themselves a "VPN" b) said browser extensions being unaware of the Chrome Extension API to set mode 4 which prevents UDP from being used if a proxy server is set. See https://voidsec.com/vpn-leak/ for the original article. Its interesting research and shows that the actual problem is not VPNs in split mode as I had assumed. From nobody Tue Apr 3 07:56:53 2018 Return-Path: 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 4C28712E6A3 for ; Tue, 3 Apr 2018 07:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hQtxovZQQ9-V for ; Tue, 3 Apr 2018 07:56:49 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7077D127AD4 for ; Tue, 3 Apr 2018 07:56:49 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id a17so4028798uaf.13 for ; Tue, 03 Apr 2018 07:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EKAvtkZVpCLRWsESZz2CTYr2SH865/+v2v45v3g0o0A=; b=mncXHaYkaQsDxianIpTuHb15XbFkcp0vqpHeK9RDZVoCzTIAI4gkQinIq9tlpVSXG9 0g1ijGWhMR0mgJrypjJmAoJVnD/xroE0y+N6s7aGhyGLpIz4t3iepHIuUAvKIWP2l/Tn ii4QKwDmmkRyO1jFI8+HkAs6qTr3tFB2shc9OGUS2/OX8KCJFylo6VJzbu6U5rlP1ZkU XEdUlFhHlWaFiKpqhJ/w3nYSKWkeucSiTrltJxL+b/pHi8/xERAffh3ee6gbCwnonpPh A6xXHIOxLF2MddZYDWQRyHbUjw/wXyMk2dTiz2Kl8OZs4mXEsHIcythXVkI29tLTwkyt HBkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EKAvtkZVpCLRWsESZz2CTYr2SH865/+v2v45v3g0o0A=; b=LNNQ+P5uJDb9u0Owy1aWzWm/0pOgJkX05ksvEknRJgz9jOpjA96MoJhTUvxfoEug9n dFlw9kDihQyQXxagWCxSuifg8dl6iNqjc8GkO3l8vClLWjUmO1nlPmPdFTbFeEwvR9sB NPh9JWaYJed8uS9BQ7ZD6y3BQMv0EzFHwApYvfc3iDjScxXT40WBzbs81VRbazZwbh69 vuTOLKUVlPPHiWBnjSKNxZf7+cPNx70Xj19/MbcViL3z6Pyn1+8xUr43jsh7RuNfMhXS iW35kauC4A7UFgi39ct8VlzQ2agVfUQq5qPVv1u0QoMH2kheAKIjL7prRIaI2+8TwOOK DLzg== X-Gm-Message-State: AElRT7FAz8udjQHHQbOwn4aHlzVxUNNYD5bTBgTOelHEcaTRX3TQvsSK qeqQ4V+yBc2c+QNhi/OcJRHSeGJTWkGclzQbm4t/Sg== X-Google-Smtp-Source: AIpwx49aNnKng8Uc3m37mP9f4myqfPzb1oDOmDKnLY3YOTxvB6kMAQFhD6MtVb3tfA4PzhVW8o6fwUczAJeAxm2Aas8= X-Received: by 10.176.19.115 with SMTP id h48mr8330114uae.135.1522767408357; Tue, 03 Apr 2018 07:56:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.50.68 with HTTP; Tue, 3 Apr 2018 07:56:47 -0700 (PDT) In-Reply-To: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> <443FC3E5-891C-49BB-90A1-C3139D3C0655@iii.ca> From: Andy Hutton Date: Tue, 3 Apr 2018 15:56:47 +0100 Message-ID: To: Philipp Hancke Cc: rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 14:56:51 -0000 On 3 April 2018 at 14:17, Philipp Hancke wrote: > Am 03.04.2018 um 11:14 schrieb T H Panton: >> >> In case anyone thinks this issue will go away if we ignore it: >> >> >> https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/ >> > > > It turned out the issue in this case is > a) browser extensions that add a proxy server calling themselves a "VPN" > b) said browser extensions being unaware of the Chrome Extension API to set > mode 4 which prevents UDP from being used if a proxy server is set. > The reference to mode 4 forced me to read that part of the draft again and now I have a question: In the description of mode 4 *https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-06#section-5.2) what is meant by "or the WebRTC implementation does not support UDP proxying"? Does "UDP Proxying" refer to the return proxy mechanism, a network specific TURN server, or something else? Andy From nobody Tue Apr 3 10:24:48 2018 Return-Path: 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 31BA912D7E8; Tue, 3 Apr 2018 10:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 rtkOJ9MPvr4j; Tue, 3 Apr 2018 10:24:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A17D124239; Tue, 3 Apr 2018 10:24:28 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w33HONFv086318 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Apr 2018 12:24:24 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Ben Campbell , Peter Saint-Andre Cc: The IESG , Flemming Andreasen , mmusic-chairs@ietf.org, draft-ietf-mmusic-trickle-ice-sip@ietf.org, mmusic@ietf.org, "ice@ietf.org" , "rtcweb@ietf.org" References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Tue, 3 Apr 2018 12:24:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:24:30 -0000 +rtcweb. This is a three-WG situation, and I suspect rtcweb participants have an opinion on the topic. /a On 4/3/18 11:55 AM, Ben Campbell wrote: > >> On Apr 3, 2018, at 11:22 AM, Peter Saint-Andre wrote: >> >> + ICE WG to address the cross-document DISCUSS only. >> >> On 4/3/18 1:29 AM, Adam Roach wrote: >> >> >> >>> The second issue doesn't necessarily pertain to this document per se as much >>> as it does the interaction among this document, draft-ietf-ice-trickle (Trickle >>> ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and draft-ietf-rtcweb-jsep >>> (JSEP). The problem doesn't lie with any single document, but in the overall >>> result of how they're currently structured. >>> >>> JSEP (in the RFC editor queue) refers to the "a=end-of-candidates" SDP attribute >>> as appearing in Trickle ICE, section 9.3, which was true at one point in time. >>> Somewhere along the line, this attribute's definition was moved from there >>> into this document. >>> >>> There are several ways to fix this, each with their own drawbacks: >>> >>> 1. Move the SDP syntax for "a=end-of-candidates" back into the Trickle ICE >>> draft. Drawback: Trickle ICE does not currently define any normative SDP >>> behavior; and, in fact, could work in a system that doesn't use SDP at all. >>> >>> 2. Move the SDP syntax into the ICE SDP draft. This is pretty elegant from the >>> perspective that ICE SDP defines SDP syntax for ICE in general (for both >>> SIP and JSEP), and such a move aggregates all of the SDP syntax into a >>> single document that is already necessary to reference from any document >>> that uses SDP for Trickle ICE. Drawback: the document doesn't presently >>> discuss Trickle ICE at all, and this would require a somewhat awkward >>> section that basically says "If you use [Trickle ICE] with SDP, the syntax >>> for the end-of-candidate marker is..." >>> >>> 3. Change JSEP to normatively depend on this document for the >>> "a=end-of-candidates" syntax. Drawback: This document is extremely >>> SIP-specific, while JSEP is based solely on RFC 4566 syntax and RFC 3264 >>> behavior, independent of any SIP semantics. Forcing JSEP to normatively >>> depend on a SIP specific document for a simple attribute syntax definition >>> seems to be letting the tail wag the dog. >>> >>> I believe that #2 is the least inelegant option, but I'm open to #1 and #3. >>> However, The *current* situation -- in which JSEP normatively points to a >>> document from which the text is cites has been removed out from under it -- is >>> clearly wrong. >> IMHO the ICE WG had consensus to remove all normative SDP references >> from draft-ietf-ice-trickle and place them in >> draft-ietf-mmusic-trickle-ice-sip. Does it really matter what kind of >> document JSEP points to, as long as the "a=end-of-candidates" definition >> can be found there? > I was working on a comment to the same effect when I saw Peter’s. > > I see Adam’s option 1 as a non-starter since it explicitly reverses that consensus. I see 2 and 3 to be equally awkward, in which case 3 requires the least amount of structural change. If there was an option that required no change to jsep at all(since it is currently with the RFC editor), but IIUC, none of the choices allow for that. > > Thanks! > > Ben. > From nobody Tue Apr 3 11:00:26 2018 Return-Path: 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 E489F12D7E8; Tue, 3 Apr 2018 10:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 SB27yzaLq0yu; Tue, 3 Apr 2018 10:35:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0611012D7E5; Tue, 3 Apr 2018 10:35:56 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w33HZrU7088315 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Apr 2018 12:35:54 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B408C13E-FC4A-41CD-9814-E8C43E6D6732"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 3 Apr 2018 12:35:52 -0500 In-Reply-To: Cc: Adam Roach , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , Peter Saint-Andre , draft-ietf-mmusic-trickle-ice-sip@ietf.org To: Eric Rescorla References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:00:22 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:35:59 -0000 --Apple-Mail=_B408C13E-FC4A-41CD-9814-E8C43E6D6732 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 3, 2018, at 12:26 PM, Eric Rescorla wrote: >=20 > I don't think #3 is acceptable. AFAIK JSEP has no other dependencies = on SIP. If you think #2 and #3 are equally awkward, lets do #2. >=20 I said they are equally awkward (by which I mean equally awkward for = readers after publication), but 3 requires fewer changes (that is, less = effort.). If we want to go for least awkward, that probably means a separate = trickle-ice-sdp draft in parallel to the ice sdp draft. But that=E2=80=99s= the past of most effort. But honestly, I think this is the sort of point that we should defer to = WG consensus. Ben. --Apple-Mail=_B408C13E-FC4A-41CD-9814-E8C43E6D6732 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrDu3gACgkQgFZKbJXz 1A0c4A/+Jje2dM1gnZrawy5A+JrKVqHwZ2oDQT59NU6u8B1tjSbB9Dg4DSMvJq9V bEFfzf68UqQBbtT82qdxtYsrCnYLqHmwfP6NxDBhIyRPCYaumoXEAnHdRuV4iWCL oYpnqmRpxWa1S7odvvF5bsoo3DCsePedxvMGI/Y88xp7QA2nX1ULu5HZhZ6GxHR2 KoAZAqbX+sB3Te4pOh3FG8HVH79D4KLkkFca+nSPQTJiK1r4SY1bbA4VcYeOmvCa 1/3+b9Hrk6FZTXxj3cs8EEAHNI0KzC4up64QmkuGU9leu6DvOiR2rZx0AOzoIEHs RnziWWWVvYBIn084KmsvxyzPmG/fYJcnrHyggct1r6U8Dl+ZJPbKn/TLT8LDDJU1 kUW/RZYaRONiKWnZU/zUOfNY+y1x+XhEvUAsxxcFyr8eLXE9Pqndu/JaQQDm/CGQ dM95sWz5WcB6x5GraMz3YAVzWqPpE0lG79uD41PrL/AR7ZR+WeKCYnobgNEBTGks xoZh55nYIwz5uq1YVacdJpcnb9n4pL6mem1htbn5wIqzKtCaE68h9ERGqK8IEddw pJfH5tPm/qCiL/KAz01Uoe/unLMp1bpdKKnl198HB9wAb3gtkbVgRayTlwY36/3O Dr8kp3XxNjBujE5H7hG8hgroQGpQWmy/srGjk700e741p88seoQ= =vtUO -----END PGP SIGNATURE----- --Apple-Mail=_B408C13E-FC4A-41CD-9814-E8C43E6D6732-- From nobody Tue Apr 3 11:00:30 2018 Return-Path: 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 0831412D778; Tue, 3 Apr 2018 10:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 nAfZgc1zd411; Tue, 3 Apr 2018 10:49:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4A61243F6; Tue, 3 Apr 2018 10:49:39 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w33HnZ43090702 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Apr 2018 12:49:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4D4B2462-31B0-44E2-8B9D-2C50238E69A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 3 Apr 2018 12:49:34 -0500 In-Reply-To: Cc: Roman Shpount , Adam Roach , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org To: Eric Rescorla References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:00:22 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:49:41 -0000 --Apple-Mail=_4D4B2462-31B0-44E2-8B9D-2C50238E69A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 3, 2018, at 12:43 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Apr 3, 2018 at 10:38 AM, Roman Shpount = wrote: >=20 >=20 >=20 > On Tue, Apr 3, 2018 at 1:26 PM, Eric Rescorla wrote: >=20 >=20 > On Tue, Apr 3, 2018 at 10:24 AM, Adam Roach wrote: > On 4/3/18 1:29 AM, Adam Roach wrote: >=20 > >=20 > The second issue doesn't necessarily pertain to this document per se = as much > as it does the interaction among this document, draft-ietf-ice-trickle = (Trickle > ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and = draft-ietf-rtcweb-jsep > (JSEP). The problem doesn't lie with any single document, but in the = overall > result of how they're currently structured. >=20 > JSEP (in the RFC editor queue) refers to the "a=3Dend-of-candidates" = SDP attribute > as appearing in Trickle ICE, section 9.3, which was true at one point = in time. > Somewhere along the line, this attribute's definition was moved from = there > into this document. >=20 > There are several ways to fix this, each with their own drawbacks: >=20 > 1. Move the SDP syntax for "a=3Dend-of-candidates" back into the = Trickle ICE > draft. Drawback: Trickle ICE does not currently define any = normative SDP > behavior; and, in fact, could work in a system that doesn't use SDP = at all. >=20 > 2. Move the SDP syntax into the ICE SDP draft. This is pretty elegant = from the > perspective that ICE SDP defines SDP syntax for ICE in general (for = both > SIP and JSEP), and such a move aggregates all of the SDP syntax = into a > single document that is already necessary to reference from any = document > that uses SDP for Trickle ICE. Drawback: the document doesn't = presently > discuss Trickle ICE at all, and this would require a somewhat = awkward > section that basically says "If you use [Trickle ICE] with SDP, the = syntax > for the end-of-candidate marker is..." >=20 > 3. Change JSEP to normatively depend on this document for the > "a=3Dend-of-candidates" syntax. Drawback: This document is = extremely > SIP-specific, while JSEP is based solely on RFC 4566 syntax and RFC = 3264 > behavior, independent of any SIP semantics. Forcing JSEP to = normatively > depend on a SIP specific document for a simple attribute syntax = definition > seems to be letting the tail wag the dog. >=20 > I believe that #2 is the least inelegant option, but I'm open to #1 = and #3. > However, The *current* situation -- in which JSEP normatively points = to a > document from which the text is cites has been removed out from under = it -- is > clearly wrong. > IMHO the ICE WG had consensus to remove all normative SDP references > from draft-ietf-ice-trickle and place them in > draft-ietf-mmusic-trickle-ice-sip. Does it really matter what kind of > document JSEP points to, as long as the "a=3Dend-of-candidates" = definition > can be found there? > I was working on a comment to the same effect when I saw Peter=E2=80=99s= . >=20 > I see Adam=E2=80=99s option 1 as a non-starter since it explicitly = reverses that consensus. I see 2 and 3 to be equally awkward, in which = case 3 requires the least amount of structural change. If there was an = option that required no change to jsep at all(since it is currently with = the RFC editor), but IIUC, none of the choices allow for that. >=20 > I don't think #3 is acceptable. AFAIK JSEP has no other dependencies = on SIP. If you think #2 and #3 are equally awkward, lets do #2. >=20 >=20 > Do you want to move all other trickle ICE specific SDP related changes = from draft-ietf-mmusic-trickle-ice-sip to = draft-ietf-mmusic-ice-sip-sdp? >=20 > It is not just end-of-candidates, but also support for c=3D0.0.0.0 in = offers, SDP offers without the candidates, different mismatch rules. As = it stands, draft-ietf-mmusic-trickle-ice-sip changes how = draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used. >=20 > I want to do whatever is necessary to remove the normative dependency = from JSEP to SIP We do references to =E2=80=9Csection XXX of RFC YYYY=E2=80=9D all the = time to refer to specific points in an RFC of larger scope. I agree = it=E2=80=99s not ideal, but =E2=80=9Cnot done=E2=80=9D is also not = ideal. Ben. --Apple-Mail=_4D4B2462-31B0-44E2-8B9D-2C50238E69A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrDvq4ACgkQgFZKbJXz 1A32oQ/9ELqhvYrRgIsPJYvpWe1hEOygoyRTHuQDYlZYkwJtqbdf6kit1bb1dwyI TmWP0LwPhJrbdYjhKhGFv9hfml6JoAYPmy6uvmqTjGy0aZSD0va1LEa6dfo25Bd7 +0shDQ93gki+aRK1AaH+xxrMGMUBAYGHFfuGZ669AkBZpCnVBb31/JBsEzOguNGE Gn4w/OxmoiDsL+rjHM3YNBdNg4ZGOVhOYOn2eOaH45BeRgRvDnzcewxFAom/496F o/vVNgzzYQk6ig4RG/5wamHftc2+7hVQEIEBmJQi5uLMmIyRwy//+TWRFideYfVB F2hpncRXCKPkcMcv/QGoOUcM3Nkf07bXkqYS+/+do0ObyZ95bRCJDSRo17DfFblW N6bIW7/G9AAHLWpWt9m7C3/3BDH4YC8oCP+qJd7spff9Pf8TX99dw4+b7wbIfr+A mEcfGbARV9bO/ek2wCXLuR6auoO4Zj0cS5bwr0OAtKgl1Gy+705E2AepHHKUC7N3 mkj3hXcUwSj6k/t4p87P5QqcJiDUuEjeKPUc04lTmKP1ZsmTPxy1qiasYOBrhozJ SFJzfdHNesaMY718yboELjekW5E8r9X0PQmd5NxVKfKS0LfSUF0XrQ60ghbIl5jY NYwwXT3CGg3ey3gdM3LdmQPUUZO2xwJ4jI92MbtwwuGPM1DingU= =Vjx/ -----END PGP SIGNATURE----- --Apple-Mail=_4D4B2462-31B0-44E2-8B9D-2C50238E69A7-- From nobody Tue Apr 3 11:00:36 2018 Return-Path: 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 1CE5212E8A4 for ; Tue, 3 Apr 2018 10:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 mg3q_srnV6rw for ; Tue, 3 Apr 2018 10:27:20 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB8C12D7E5 for ; Tue, 3 Apr 2018 10:27:20 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id e123-v6so16682635oih.13 for ; Tue, 03 Apr 2018 10:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G1O9nTQ4sadQaByb4/ey+xHWYMSBZAQ4eH3tlOAnrgU=; b=zxs+IRIGNShwuDXo/bhCiGPdCmXx411cc0biRt0in8w7mnyF3fpiJ+TnwIq29vHZsD 1EaJ8/7ZOdklB4inz5V4lMx+1Jyrqi7r6jRJzAgzTKtJbHm1uN2iLbO7CZsgIEeybvrs 8BSWYB27KdMHim4ZBEK/RMcOYrtyVXC1GqAifCn0CMdSONFFhZZLkWpnSA1VqOngdjvU 93/hNnAqdJV4498cWuerD3kFutuA7cWM8lkJZ9M/U3xw9ClBHnWTGVJIcbkZet+v8tfq 5BU78D0M1zCQuCCEYBcLHf34AMMJV7bwT+FrvSGpbfanLxA6aDUba8rMiuvQd6GwOz2Q EyJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G1O9nTQ4sadQaByb4/ey+xHWYMSBZAQ4eH3tlOAnrgU=; b=Bci/y0QwUbQe7RBu6RXnGVl1q0cF2YEUyqaFYHKtgmI+oDYld3PQkt9JXqsNotVSYJ Ki69qhl2oczfbyW7ozbgnPdSAJ90qQUiqMiBY/OIxdkNhJ2R6TCeOP2owgACbEa/4x9U hOXQHOj57sCjo4tKSIliY+MwRpLE770JrCK9nK2TBV6TFZbGE6aZDrALzfFtvLS07u4H hGEHAu+3yqr2IgJbx1WIOGW97jbCims/WUpPTeCrrA0/GssC887sqJ7XsrgDtMhJnpk7 17SfrMA60dlq+eMoh33hF6hE4C6CcefsEciip3Rtxd2c2DZ8rSnfn/0hKPrMT1cWi5u/ FrAg== X-Gm-Message-State: ALQs6tD9t+Mi6a296j1Q3QKo3OxPWLe0e6cZzCJWZVDbpP1T8+h521CG eDKVUWwhW4HXUci3d/tXkmpou9+UYFOIg5ItxZ5yIw== X-Google-Smtp-Source: AIpwx4+Un7e+7Va9JzAIHX1EWkvd2b/zoro/1EhceaibBYa5mpKhI4NxSnwz0Rrda1ry9rYHma+vRckImraVLyuRE4Y= X-Received: by 2002:aca:cc53:: with SMTP id c80-v6mr8207674oig.174.1522776439907; Tue, 03 Apr 2018 10:27:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Tue, 3 Apr 2018 10:26:39 -0700 (PDT) In-Reply-To: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Tue, 3 Apr 2018 10:26:39 -0700 Message-ID: To: Adam Roach Cc: Ben Campbell , Peter Saint-Andre , mmusic-chairs@ietf.org, mmusic WG , "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org Content-Type: multipart/alternative; boundary="000000000000c601cc0568f504b6" Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:00:22 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:27:23 -0000 --000000000000c601cc0568f504b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 3, 2018 at 10:24 AM, Adam Roach wrote: > +rtcweb. This is a three-WG situation, and I suspect rtcweb participants > have an opinion on the topic. > > /a > > > On 4/3/18 11:55 AM, Ben Campbell wrote: > >> >> On Apr 3, 2018, at 11:22 AM, Peter Saint-Andre >>> wrote: >>> >>> + ICE WG to address the cross-document DISCUSS only. >>> >>> On 4/3/18 1:29 AM, Adam Roach wrote: >>> >>> >>> >>> The second issue doesn't necessarily pertain to this document per se as >>>> much >>>> as it does the interaction among this document, draft-ietf-ice-trickle >>>> (Trickle >>>> ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and >>>> draft-ietf-rtcweb-jsep >>>> (JSEP). The problem doesn't lie with any single document, but in the >>>> overall >>>> result of how they're currently structured. >>>> >>>> JSEP (in the RFC editor queue) refers to the "a=3Dend-of-candidates" S= DP >>>> attribute >>>> as appearing in Trickle ICE, section 9.3, which was true at one point >>>> in time. >>>> Somewhere along the line, this attribute's definition was moved from >>>> there >>>> into this document. >>>> >>>> There are several ways to fix this, each with their own drawbacks: >>>> >>>> 1. Move the SDP syntax for "a=3Dend-of-candidates" back into the Trick= le >>>> ICE >>>> draft. Drawback: Trickle ICE does not currently define any normativ= e >>>> SDP >>>> behavior; and, in fact, could work in a system that doesn't use SDP >>>> at all. >>>> >>>> 2. Move the SDP syntax into the ICE SDP draft. This is pretty elegant >>>> from the >>>> perspective that ICE SDP defines SDP syntax for ICE in general (for >>>> both >>>> SIP and JSEP), and such a move aggregates all of the SDP syntax int= o >>>> a >>>> single document that is already necessary to reference from any >>>> document >>>> that uses SDP for Trickle ICE. Drawback: the document doesn't >>>> presently >>>> discuss Trickle ICE at all, and this would require a somewhat awkwa= rd >>>> section that basically says "If you use [Trickle ICE] with SDP, the >>>> syntax >>>> for the end-of-candidate marker is..." >>>> >>>> 3. Change JSEP to normatively depend on this document for the >>>> "a=3Dend-of-candidates" syntax. Drawback: This document is extremel= y >>>> SIP-specific, while JSEP is based solely on RFC 4566 syntax and RFC >>>> 3264 >>>> behavior, independent of any SIP semantics. Forcing JSEP to >>>> normatively >>>> depend on a SIP specific document for a simple attribute syntax >>>> definition >>>> seems to be letting the tail wag the dog. >>>> >>>> I believe that #2 is the least inelegant option, but I'm open to #1 an= d >>>> #3. >>>> However, The *current* situation -- in which JSEP normatively points t= o >>>> a >>>> document from which the text is cites has been removed out from under >>>> it -- is >>>> clearly wrong. >>>> >>> IMHO the ICE WG had consensus to remove all normative SDP references >>> from draft-ietf-ice-trickle and place them in >>> draft-ietf-mmusic-trickle-ice-sip. Does it really matter what kind of >>> document JSEP points to, as long as the "a=3Dend-of-candidates" definit= ion >>> can be found there? >>> >> I was working on a comment to the same effect when I saw Peter=E2=80=99s= . >> >> I see Adam=E2=80=99s option 1 as a non-starter since it explicitly rever= ses that >> consensus. I see 2 and 3 to be equally awkward, in which case 3 requires >> the least amount of structural change. If there was an option that requi= red >> no change to jsep at all(since it is currently with the RFC editor), but >> IIUC, none of the choices allow for that. >> > I don't think #3 is acceptable. AFAIK JSEP has no other dependencies on SIP. If you think #2 and #3 are equally awkward, lets do #2. -Ekr >> Thanks! >> >> Ben. >> >> > --000000000000c601cc0568f504b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 3, 2018 at 10:24 AM, Adam Roach <adam@nostrum.com> wrote:
+rtcweb. This is a three-WG = situation, and I suspect rtcweb participants have an opinion on the topic.<= span class=3D"HOEnZb">

/a


On 4/3/18 11:55 AM, Ben Campbell wrote:

On Apr 3, 2018, at 11:22 AM, Peter Saint-Andre <stpeter@mozilla.com> wrote:

+ ICE WG to address the cross-document DISCUSS only.

On 4/3/18 1:29 AM, Adam Roach wrote:

<snip/>

The second issue doesn't necessarily pertain to this document per se as= much
as it does the interaction among this document, draft-ietf-ice-trickle (Tri= ckle
ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and draft-ietf-rtcweb-jsep (JSEP). The problem doesn't lie with any single document, but in the ov= erall
result of how they're currently structured.

JSEP (in the RFC editor queue) refers to the "a=3Dend-of-candidates&qu= ot; SDP attribute
as appearing in Trickle ICE, section 9.3, which was true at one point in ti= me.
Somewhere along the line, this attribute's definition was moved from th= ere
into this document.

There are several ways to fix this, each with their own drawbacks:

1. Move the SDP syntax for "a=3Dend-of-candidates" back into the = Trickle ICE
=C2=A0 =C2=A0draft. Drawback: Trickle ICE does not currently define any nor= mative SDP
=C2=A0 =C2=A0behavior; and, in fact, could work in a system that doesn'= t use SDP at all.

2. Move the SDP syntax into the ICE SDP draft. This is pretty elegant from = the
=C2=A0 =C2=A0perspective that ICE SDP defines SDP syntax for ICE in general= (for both
=C2=A0 =C2=A0SIP and JSEP), and such a move aggregates all of the SDP synta= x into a
=C2=A0 =C2=A0single document that is already necessary to reference from an= y document
=C2=A0 =C2=A0that uses SDP for Trickle ICE. Drawback: the document doesn= 9;t presently
=C2=A0 =C2=A0discuss Trickle ICE at all, and this would require a somewhat = awkward
=C2=A0 =C2=A0section that basically says "If you use [Trickle ICE] wit= h SDP, the syntax
=C2=A0 =C2=A0for the end-of-candidate marker is..."

3. Change JSEP to normatively depend on this document for the
=C2=A0 =C2=A0"a=3Dend-of-candidates" syntax. Drawback: This docum= ent is extremely
=C2=A0 =C2=A0SIP-specific, while JSEP is based solely on RFC 4566 syntax an= d RFC 3264
=C2=A0 =C2=A0behavior, independent of any SIP semantics.=C2=A0 Forcing JSEP= to normatively
=C2=A0 =C2=A0depend on a SIP specific document for a simple attribute synta= x definition
=C2=A0 =C2=A0seems to be letting the tail wag the dog.

I believe that #2 is the least inelegant option, but I'm open to #1 and= #3.
However, The *current* situation -- in which JSEP normatively points to a document from which the text is cites has been removed out from under it --= is
clearly wrong.
IMHO the ICE WG had consensus to remove all normative SDP references
from draft-ietf-ice-trickle and place them in
draft-ietf-mmusic-trickle-ice-sip. Does it really matter what kind of<= br> document JSEP points to, as long as the "a=3Dend-of-candidates" d= efinition
can be found there?
I was working on a comment to the same effect when I saw Peter=E2=80=99s.
I see Adam=E2=80=99s option 1 as a non-starter since it explicitly reverses= that consensus. I see 2 and 3 to be equally awkward, in which case 3 requi= res the least amount of structural change. If there was an option that requ= ired no change to jsep at all(since it is currently with the RFC editor), b= ut IIUC, none of the choices allow for that.

I don't think #3 is acceptable. AFAIK JS= EP has no other dependencies on SIP. If you think #2 and #3 are equally awk= ward, lets do #2.

-Ekr


Thanks!

Ben.



--000000000000c601cc0568f504b6-- From nobody Tue Apr 3 11:00:49 2018 Return-Path: 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 C66C012D7EA for ; Tue, 3 Apr 2018 10:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 AjfgnQ6rr4KP for ; Tue, 3 Apr 2018 10:38:56 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B4512EADA for ; Tue, 3 Apr 2018 10:38:43 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id x4-v6so9818827pln.7 for ; Tue, 03 Apr 2018 10:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r0jnHAg/mfl7AF7pE4yFS9tRKui789opIZmUZylMp2Q=; b=ogI3rVhbqRR7FEOXvkLHM+rIBXcIPAxI7EKOkCEQLGoJDwn9Cn05OyoVVgAWcN/p16 x5R5AsxXiTKnKltb1EmkNPzZm5yZ9iwVKNQekdScg+Yey9nEeDqxtYNtT0MoFquFinK1 7sCIw+YBnna2SRKbfnGkB4HXzNsHIkhPWDFNB+iK1tdGIiR8MALjjSjkTd53I4gZRU5J 0xP+d+bYBkgXjQF3lBwncilbjRlFHrCm+e+V8bzW5mN9e5y7Ksu0hGYWq7nFXiCYZEor Iijz3TJnoNbm+k/+wFxPAtjZfchogwpvqRpmhElxHbeJY5bkF3dq1U+DXxh4j9sXOoJh /qpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r0jnHAg/mfl7AF7pE4yFS9tRKui789opIZmUZylMp2Q=; b=Z/XyGa4icHFJAACmjKWftuD4gnQDfYc9C/GEj40jGHIR9AMC4hA0gIH8hM1zOwneow YQZX200MfnnwBY4mDnuxZBu9cUqGz4vgW8nPOY20dd0cUiHepDQSfUkVqEqCZX03a/Su 7S+DNt8IvoJBlqctgAe9dcig27shsfQX2iCeUhOi9WshA/L6rRfH3TzH4rGrofG8zDGp 8euv01dUA5fFOJ9PiewXx0s18+h+fs51yGxRkMf+9PpX0l4BAdBbzVzzLLXFzYs8pA2x qL4+UYjo95JyJlvQrFyzeXbrA3XTL6mS+GQW0rPQsNxMsujnkp55IFfm2UKa1qCVLBT0 ElDQ== X-Gm-Message-State: AElRT7FMEXmmqkd3KNfW3i9XCKkVdQgydH1CN/rd0vd0sCsfFlVjRmlb PGOOF3cl+Ia174kKbd3CZAdTjQ== X-Google-Smtp-Source: AIpwx498FnUeZ4XCg7hdEq1PKhaP+zWG4f44HZsYgATHlLFb7En1FHOmZPAj1xsTUPVyfJrKQx53QQ== X-Received: by 2002:a17:902:566:: with SMTP id 93-v6mr14653900plf.327.1522777122694; Tue, 03 Apr 2018 10:38:42 -0700 (PDT) Received: from mail-pl0-f54.google.com (mail-pl0-f54.google.com. [209.85.160.54]) by smtp.gmail.com with ESMTPSA id f86sm6183078pfk.153.2018.04.03.10.38.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 10:38:41 -0700 (PDT) Received: by mail-pl0-f54.google.com with SMTP id b6-v6so7846326pla.11; Tue, 03 Apr 2018 10:38:41 -0700 (PDT) X-Received: by 2002:a17:902:8d84:: with SMTP id v4-v6mr14819021plo.215.1522777121234; Tue, 03 Apr 2018 10:38:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.102 with HTTP; Tue, 3 Apr 2018 10:38:39 -0700 (PDT) In-Reply-To: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> From: Roman Shpount Date: Tue, 3 Apr 2018 13:38:39 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: Adam Roach , Ben Campbell , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org Content-Type: multipart/alternative; boundary="00000000000062241f0568f52d24" Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:00:22 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:38:59 -0000 --00000000000062241f0568f52d24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 3, 2018 at 1:26 PM, Eric Rescorla wrote: > > > On Tue, Apr 3, 2018 at 10:24 AM, Adam Roach wrote: > >> On 4/3/18 1:29 AM, Adam Roach wrote: >>>> >>>> >>>> >>>> The second issue doesn't necessarily pertain to this document per se a= s >>>>> much >>>>> as it does the interaction among this document, draft-ietf-ice-trickl= e >>>>> (Trickle >>>>> ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and >>>>> draft-ietf-rtcweb-jsep >>>>> (JSEP). The problem doesn't lie with any single document, but in the >>>>> overall >>>>> result of how they're currently structured. >>>>> >>>>> JSEP (in the RFC editor queue) refers to the "a=3Dend-of-candidates" = SDP >>>>> attribute >>>>> as appearing in Trickle ICE, section 9.3, which was true at one point >>>>> in time. >>>>> Somewhere along the line, this attribute's definition was moved from >>>>> there >>>>> into this document. >>>>> >>>>> There are several ways to fix this, each with their own drawbacks: >>>>> >>>>> 1. Move the SDP syntax for "a=3Dend-of-candidates" back into the Tric= kle >>>>> ICE >>>>> draft. Drawback: Trickle ICE does not currently define any >>>>> normative SDP >>>>> behavior; and, in fact, could work in a system that doesn't use SD= P >>>>> at all. >>>>> >>>>> 2. Move the SDP syntax into the ICE SDP draft. This is pretty elegant >>>>> from the >>>>> perspective that ICE SDP defines SDP syntax for ICE in general (fo= r >>>>> both >>>>> SIP and JSEP), and such a move aggregates all of the SDP syntax >>>>> into a >>>>> single document that is already necessary to reference from any >>>>> document >>>>> that uses SDP for Trickle ICE. Drawback: the document doesn't >>>>> presently >>>>> discuss Trickle ICE at all, and this would require a somewhat >>>>> awkward >>>>> section that basically says "If you use [Trickle ICE] with SDP, th= e >>>>> syntax >>>>> for the end-of-candidate marker is..." >>>>> >>>>> 3. Change JSEP to normatively depend on this document for the >>>>> "a=3Dend-of-candidates" syntax. Drawback: This document is extreme= ly >>>>> SIP-specific, while JSEP is based solely on RFC 4566 syntax and RF= C >>>>> 3264 >>>>> behavior, independent of any SIP semantics. Forcing JSEP to >>>>> normatively >>>>> depend on a SIP specific document for a simple attribute syntax >>>>> definition >>>>> seems to be letting the tail wag the dog. >>>>> >>>>> I believe that #2 is the least inelegant option, but I'm open to #1 >>>>> and #3. >>>>> However, The *current* situation -- in which JSEP normatively points >>>>> to a >>>>> document from which the text is cites has been removed out from under >>>>> it -- is >>>>> clearly wrong. >>>>> >>>> IMHO the ICE WG had consensus to remove all normative SDP references >>>> from draft-ietf-ice-trickle and place them in >>>> draft-ietf-mmusic-trickle-ice-sip. Does it really matter what kind of >>>> document JSEP points to, as long as the "a=3Dend-of-candidates" defini= tion >>>> can be found there? >>>> >>> I was working on a comment to the same effect when I saw Peter=E2=80=99= s. >>> >>> I see Adam=E2=80=99s option 1 as a non-starter since it explicitly reve= rses that >>> consensus. I see 2 and 3 to be equally awkward, in which case 3 require= s >>> the least amount of structural change. If there was an option that requ= ired >>> no change to jsep at all(since it is currently with the RFC editor), bu= t >>> IIUC, none of the choices allow for that. >>> >> > I don't think #3 is acceptable. AFAIK JSEP has no other dependencies on > SIP. If you think #2 and #3 are equally awkward, lets do #2. > > Do you want to move all other trickle ICE specific SDP related changes from draft-ietf-mmusic-trickle-ice-sip to draft-ietf-mmusic-ice-sip-sdp? It is not just end-of-candidates, but also support for c=3D0.0.0.0 in offer= s, SDP offers without the candidates, different mismatch rules. As it stands, draft-ietf-mmusic-trickle-ice-sip changes how draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used. Regards, _____________ Roman Shpount --00000000000062241f0568f52d24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Tue, Apr 3, 2018 at 1:26 PM, Eric Rescorla= <ek= r@rtfm.com> wrote:


On Tue, Apr 3, 2018 at 10:24 AM, Adam Roach <adam@nostru= m.com> wrote:
On 4/3/18 1:29 AM, = Adam Roach wrote:

<snip/>

The second issue doesn't necessarily pertain to this document per se as= much
as it does the interaction among this document, draft-ietf-ice-trickle (Tri= ckle
ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and draft-ietf-rtcweb-jsep (JSEP). The problem doesn't lie with any single document, but in the ov= erall
result of how they're currently structured.

JSEP (in the RFC editor queue) refers to the "a=3Dend-of-candidates&qu= ot; SDP attribute
as appearing in Trickle ICE, section 9.3, which was true at one point in ti= me.
Somewhere along the line, this attribute's definition was moved from th= ere
into this document.

There are several ways to fix this, each with their own drawbacks:

1. Move the SDP syntax for "a=3Dend-of-candidates" back into the = Trickle ICE
=C2=A0 =C2=A0draft. Drawback: Trickle ICE does not currently define any nor= mative SDP
=C2=A0 =C2=A0behavior; and, in fact, could work in a system that doesn'= t use SDP at all.

2. Move the SDP syntax into the ICE SDP draft. This is pretty elegant from = the
=C2=A0 =C2=A0perspective that ICE SDP defines SDP syntax for ICE in general= (for both
=C2=A0 =C2=A0SIP and JSEP), and such a move aggregates all of the SDP synta= x into a
=C2=A0 =C2=A0single document that is already necessary to reference from an= y document
=C2=A0 =C2=A0that uses SDP for Trickle ICE. Drawback: the document doesn= 9;t presently
=C2=A0 =C2=A0discuss Trickle ICE at all, and this would require a somewhat = awkward
=C2=A0 =C2=A0section that basically says "If you use [Trickle ICE] wit= h SDP, the syntax
=C2=A0 =C2=A0for the end-of-candidate marker is..."

3. Change JSEP to normatively depend on this document for the
=C2=A0 =C2=A0"a=3Dend-of-candidates" syntax. Drawback: This docum= ent is extremely
=C2=A0 =C2=A0SIP-specific, while JSEP is based solely on RFC 4566 syntax an= d RFC 3264
=C2=A0 =C2=A0behavior, independent of any SIP semantics.=C2=A0 Forcing JSEP= to normatively
=C2=A0 =C2=A0depend on a SIP specific document for a simple attribute synta= x definition
=C2=A0 =C2=A0seems to be letting the tail wag the dog.

I believe that #2 is the least inelegant option, but I'm open to #1 and= #3.
However, The *current* situation -- in which JSEP normatively points to a document from which the text is cites has been removed out from under it --= is
clearly wrong.
IMHO the ICE WG had consensus to remove all normative SDP references
from draft-ietf-ice-trickle and place them in
draft-ietf-mmusic-trickle-ice-sip. Does it really matter what kind of<= br> document JSEP points to, as long as the "a=3Dend-of-candidates" d= efinition
can be found there?
I was working on a comment to the same effect when I saw Peter=E2=80=99s.
I see Adam=E2=80=99s option 1 as a non-starter since it explicitly reverses= that consensus. I see 2 and 3 to be equally awkward, in which case 3 requi= res the least amount of structural change. If there was an option that requ= ired no change to jsep at all(since it is currently with the RFC editor), b= ut IIUC, none of the choices allow for that.

I don't think #3 is acceptab= le. AFAIK JSEP has no other dependencies on SIP. If you think #2 and #3 are= equally awkward, lets do #2.


Do you want to move all other trickle ICE specific= SDP related changes from =C2=A0draft-ietf-mmusic-trickle-ice-sip to draft-= ietf-mmusic-ice-sip-sdp?

It is not just end-of-candidates, but also support for c= =3D0.0.0.0 in offers, SDP offers without the candidates, different mismatch= rules. As it stands,=C2=A0 draft-ietf-mmusic-trickle-ice-sip=C2=A0cha= nges how=C2=A0draft-ietf-mmusic-ice-sip-sdp=C2=A0works when trickle ICE is used.

=
Regards,
<= div class=3D"gmail_signature">_____________
Roman Shpount
=C2=A0
--00000000000062241f0568f52d24-- From nobody Tue Apr 3 11:00:59 2018 Return-Path: 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 8BE8D12D7E5 for ; Tue, 3 Apr 2018 10:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 1FesqG5rOZJ9 for ; Tue, 3 Apr 2018 10:43:45 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF87C12EA53 for ; Tue, 3 Apr 2018 10:43:42 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id v64-v6so20307976otb.13 for ; Tue, 03 Apr 2018 10:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tE9HlUbly+CiDnlEaCOYfi08zdkA8PkOcCK6gnWiEmI=; b=pISTsTrVmvTrgfo+xknkhFWxX5XOslVKnF6G0lTMhKqkX7fgyWlpCTjXPmHiK0Oz0O Ob/7J7ZghHJKdwQclILRit1DUU2MQuTGXMxvcQUts+7+3we69onY8sRgkSuIREqZk4OW AfeiFRHX36oRVXS1YkxxwL6ChCLDHfnQfpup1ozRyLzKP+6MHnRSkEuCmXpm18A4wgGh EFsemtdJ7xB5WSxFf16nyez4u5e7882l3zZFcFkHZxr2t5L7zLHw8BNjDH0e7HD1/zcN QOBlI24t2Hrv2Z4dF0HiQ3WpoewufPbfDCafLb+2PWC814lTEdkuDnn7lcfEEEmf8gAj tjpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tE9HlUbly+CiDnlEaCOYfi08zdkA8PkOcCK6gnWiEmI=; b=sXlY6vspIvlq5GkC/Wgd6vWZIUDdVeuvGRt4BM3aeJYPY4RuPazz4ZNcxB09CNxbLW kWAMp7Xan97SuQXjVP1GN3RV2+j9BC1qTb5OPJr9+/Zyez2qokW6DENFb8+3W9S3c7Yp 2M9qMIgoTTHgU1zNKKSJ2GG1sdpSiwHWumYHSWPawgHJRoqceR/1QL1NHJqR6vWPi9tM hpRc2LDp/GR4lxje67gxrDfdHXQqG+PTZswazuuMMD8VoGMXO5W6pRNZ7P+SDbmfAgzU 5fojnK0310DWaJ5kNVUTWo5Aul88ZgrqKvbo1HR/WcOLmXr6clIJv7kc7Tu4Rt9UmwDb DmXQ== X-Gm-Message-State: ALQs6tDl3KUxrZhri9OSSIWUn4AhTPAa514qsiMu5yweR9+FCKNHO4+V F61BKchII/JZS9knSrye2MOZVNmGWq8s0Oru20pkWw== X-Google-Smtp-Source: AIpwx49170UyZZP306Vxy3u3NlPB1qF1gIJiVcfDff6NEc4zyRumGbc327wYOdU7nr5O5rwnXezRuletSRAR/cUskcg= X-Received: by 2002:a9d:4289:: with SMTP id r9-v6mr9192797ote.44.1522777422318; Tue, 03 Apr 2018 10:43:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Tue, 3 Apr 2018 10:43:01 -0700 (PDT) In-Reply-To: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Tue, 3 Apr 2018 10:43:01 -0700 Message-ID: To: Roman Shpount Cc: Adam Roach , Ben Campbell , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org Content-Type: multipart/alternative; boundary="0000000000005467310568f53f55" Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:00:22 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:43:48 -0000 --0000000000005467310568f53f55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 3, 2018 at 10:38 AM, Roman Shpount wrote: > > > > On Tue, Apr 3, 2018 at 1:26 PM, Eric Rescorla wrote: > >> >> >> On Tue, Apr 3, 2018 at 10:24 AM, Adam Roach wrote: >> >>> On 4/3/18 1:29 AM, Adam Roach wrote: >>>>> >>>>> >>>>> >>>>> The second issue doesn't necessarily pertain to this document per se >>>>>> as much >>>>>> as it does the interaction among this document, >>>>>> draft-ietf-ice-trickle (Trickle >>>>>> ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and >>>>>> draft-ietf-rtcweb-jsep >>>>>> (JSEP). The problem doesn't lie with any single document, but in the >>>>>> overall >>>>>> result of how they're currently structured. >>>>>> >>>>>> JSEP (in the RFC editor queue) refers to the "a=3Dend-of-candidates" >>>>>> SDP attribute >>>>>> as appearing in Trickle ICE, section 9.3, which was true at one poin= t >>>>>> in time. >>>>>> Somewhere along the line, this attribute's definition was moved from >>>>>> there >>>>>> into this document. >>>>>> >>>>>> There are several ways to fix this, each with their own drawbacks: >>>>>> >>>>>> 1. Move the SDP syntax for "a=3Dend-of-candidates" back into the >>>>>> Trickle ICE >>>>>> draft. Drawback: Trickle ICE does not currently define any >>>>>> normative SDP >>>>>> behavior; and, in fact, could work in a system that doesn't use >>>>>> SDP at all. >>>>>> >>>>>> 2. Move the SDP syntax into the ICE SDP draft. This is pretty elegan= t >>>>>> from the >>>>>> perspective that ICE SDP defines SDP syntax for ICE in general >>>>>> (for both >>>>>> SIP and JSEP), and such a move aggregates all of the SDP syntax >>>>>> into a >>>>>> single document that is already necessary to reference from any >>>>>> document >>>>>> that uses SDP for Trickle ICE. Drawback: the document doesn't >>>>>> presently >>>>>> discuss Trickle ICE at all, and this would require a somewhat >>>>>> awkward >>>>>> section that basically says "If you use [Trickle ICE] with SDP, >>>>>> the syntax >>>>>> for the end-of-candidate marker is..." >>>>>> >>>>>> 3. Change JSEP to normatively depend on this document for the >>>>>> "a=3Dend-of-candidates" syntax. Drawback: This document is extrem= ely >>>>>> SIP-specific, while JSEP is based solely on RFC 4566 syntax and >>>>>> RFC 3264 >>>>>> behavior, independent of any SIP semantics. Forcing JSEP to >>>>>> normatively >>>>>> depend on a SIP specific document for a simple attribute syntax >>>>>> definition >>>>>> seems to be letting the tail wag the dog. >>>>>> >>>>>> I believe that #2 is the least inelegant option, but I'm open to #1 >>>>>> and #3. >>>>>> However, The *current* situation -- in which JSEP normatively points >>>>>> to a >>>>>> document from which the text is cites has been removed out from unde= r >>>>>> it -- is >>>>>> clearly wrong. >>>>>> >>>>> IMHO the ICE WG had consensus to remove all normative SDP references >>>>> from draft-ietf-ice-trickle and place them in >>>>> draft-ietf-mmusic-trickle-ice-sip. Does it really matter what kind of >>>>> document JSEP points to, as long as the "a=3Dend-of-candidates" >>>>> definition >>>>> can be found there? >>>>> >>>> I was working on a comment to the same effect when I saw Peter=E2=80= =99s. >>>> >>>> I see Adam=E2=80=99s option 1 as a non-starter since it explicitly rev= erses >>>> that consensus. I see 2 and 3 to be equally awkward, in which case 3 >>>> requires the least amount of structural change. If there was an option= that >>>> required no change to jsep at all(since it is currently with the RFC >>>> editor), but IIUC, none of the choices allow for that. >>>> >>> >> I don't think #3 is acceptable. AFAIK JSEP has no other dependencies on >> SIP. If you think #2 and #3 are equally awkward, lets do #2. >> >> > Do you want to move all other trickle ICE specific SDP related changes > from draft-ietf-mmusic-trickle-ice-sip to draft-ietf-mmusic-ice-sip-sdp? > > It is not just end-of-candidates, but also support for c=3D0.0.0.0 in > offers, SDP offers without the candidates, different mismatch rules. As i= t > stands, draft-ietf-mmusic-trickle-ice-sip changes how > draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used. > I want to do whatever is necessary to remove the normative dependency from JSEP to SIP -Ekr > Regards, > _____________ > Roman Shpount > > > --0000000000005467310568f53f55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 3, 2018 at 10:38 AM, Roman Shpount <roman@telurix.com&= gt; wrote:



On Tue, Apr 3, 2018 at 1:26 PM= , Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Apr 3, 2018 at 10:24 AM, Adam Roach <adam@nostrum.com>= wrote:
On 4/3/18 1:29 AM, Adam Roach wrote= :

<snip/>

The second issue doesn't necessarily pertain to this document per se as= much
as it does the interaction among this document, draft-ietf-ice-trickle (Tri= ckle
ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and draft-ietf-rtcweb-jsep (JSEP). The problem doesn't lie with any single document, but in the ov= erall
result of how they're currently structured.

JSEP (in the RFC editor queue) refers to the "a=3Dend-of-candidates&qu= ot; SDP attribute
as appearing in Trickle ICE, section 9.3, which was true at one point in ti= me.
Somewhere along the line, this attribute's definition was moved from th= ere
into this document.

There are several ways to fix this, each with their own drawbacks:

1. Move the SDP syntax for "a=3Dend-of-candidates" back into the = Trickle ICE
=C2=A0 =C2=A0draft. Drawback: Trickle ICE does not currently define any nor= mative SDP
=C2=A0 =C2=A0behavior; and, in fact, could work in a system that doesn'= t use SDP at all.

2. Move the SDP syntax into the ICE SDP draft. This is pretty elegant from = the
=C2=A0 =C2=A0perspective that ICE SDP defines SDP syntax for ICE in general= (for both
=C2=A0 =C2=A0SIP and JSEP), and such a move aggregates all of the SDP synta= x into a
=C2=A0 =C2=A0single document that is already necessary to reference from an= y document
=C2=A0 =C2=A0that uses SDP for Trickle ICE. Drawback: the document doesn= 9;t presently
=C2=A0 =C2=A0discuss Trickle ICE at all, and this would require a somewhat = awkward
=C2=A0 =C2=A0section that basically says "If you use [Trickle ICE] wit= h SDP, the syntax
=C2=A0 =C2=A0for the end-of-candidate marker is..."

3. Change JSEP to normatively depend on this document for the
=C2=A0 =C2=A0"a=3Dend-of-candidates" syntax. Drawback: This docum= ent is extremely
=C2=A0 =C2=A0SIP-specific, while JSEP is based solely on RFC 4566 syntax an= d RFC 3264
=C2=A0 =C2=A0behavior, independent of any SIP semantics.=C2=A0 Forcing JSEP= to normatively
=C2=A0 =C2=A0depend on a SIP specific document for a simple attribute synta= x definition
=C2=A0 =C2=A0seems to be letting the tail wag the dog.

I believe that #2 is the least inelegant option, but I'm open to #1 and= #3.
However, The *current* situation -- in which JSEP normatively points to a document from which the text is cites has been removed out from under it --= is
clearly wrong.
IMHO the ICE WG had consensus to remove all normative SDP references
from draft-ietf-ice-trickle and place them in
draft-ietf-mmusic-trickle-ice-sip. Does it really matter what kind of<= br> document JSEP points to, as long as the "a=3Dend-of-candidates" d= efinition
can be found there?
I was working on a comment to the same effect when I saw Peter=E2=80=99s.
I see Adam=E2=80=99s option 1 as a non-starter since it explicitly reverses= that consensus. I see 2 and 3 to be equally awkward, in which case 3 requi= res the least amount of structural change. If there was an option that requ= ired no change to jsep at all(since it is currently with the RFC editor), b= ut IIUC, none of the choices allow for that.

I don't think #3 is acceptable. AFAIK JSEP has no other dependencies= on SIP. If you think #2 and #3 are equally awkward, lets do #2.
<= div>

Do = you want to move all other trickle ICE specific SDP related changes from = =C2=A0draft-ietf-mmusic-trickle-ice-sip to draft-ietf-mmusic-ice-sip-s= dp?

It= is not just end-of-candidates, but also support for c=3D0.0.0.0 in offers,= SDP offers without the candidates, different mismatch rules. As it stands,= =C2=A0 draft-ietf-mmusic-trickle-ice-sip=C2= =A0changes how=C2=A0draft-ietf-mmusic-ice-sip-sdp=C2=A0works when trickle ICE is used.

I want to do whatever is necessary to remove the n= ormative dependency from JSEP to SIP

-Ekr


Regards,
<= div class=3D"m_3143575829003259321gmail_signature">_____________
Roman Shpount

=C2=A0

--0000000000005467310568f53f55-- From nobody Tue Apr 3 11:01:10 2018 Return-Path: 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 E4FD812EA42 for ; Tue, 3 Apr 2018 10:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 WIfQMuPO6LHK for ; Tue, 3 Apr 2018 10:44:46 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F78E12EAD1 for ; Tue, 3 Apr 2018 10:44:39 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id y46-v6so20339639otd.4 for ; Tue, 03 Apr 2018 10:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TUjegsqoiwL3SLwaBbImu0Oi+scGVMqqQEs2rJdTsW0=; b=EescMfCDFtKo7INuYz4kThZWiNlkpsgG1yWyu7bYc47vJmnCiadY4UaIN7vyHwtc3n NzyvCktJ9HiAeV8ynw7CoN3LYotumnMVXYu0BKbnJ05ImRR+Ho6EC3BwJAZoy1a7Eoqc 5OGMW6iFgVF25Dhh25rn+iaSLiesPaAgjLC5bmSlu+VZ2kHDjfGMTJagXyrb1MIFG06R Vf5F/isYQlJVV1sH1+VPLz87nIlTQn1TO1ehNWn4WlYh6qdk4UzHC/emLK4qDOeFbbKw rSNpZT09krJLijoLK8keha/713KuSEOP6F8M3wxjEoBuhg7Leqsled8tyeLw7eOjmPJy B5Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TUjegsqoiwL3SLwaBbImu0Oi+scGVMqqQEs2rJdTsW0=; b=GYjRtfs3cnWn3FnIHhaRiMHC83D0++A0Qxksvz8OKXhWZ9TaZQWY/kk/EGd1HrADP0 EonupBE4E2WCHKKed4dxXaWetBnFnwug7hcu8sksFSL2HgYzSgVzYUsOIJttMiA1YWwA a2msYD8THP1dGfTN4kwaUu7favECiY+39J4P95PYfWpH6XCKypFu2lHDKuVxH/Y66Mqs 1LL8151GT+zW4iDS8ApL/kmankKQN7R0hHFZ15E/aah/rYxthoerk+AQ3uHmruyDnUh9 9Uqne/KtUeb05XxK9WJSeRHQP0FB5cz9HXcYjBGsnMtMUnOQlpAeLWCAzkxfKfqbVaBb nVwQ== X-Gm-Message-State: ALQs6tD/Atdsct1Im4Owo4HrUIaeldDFHB7hAAU+Lbidoo/PnPYW5oHs 4+lrdqjL4uk7v8GkNfJs4kRDrFI7eSagB0h6PaPzCQ== X-Google-Smtp-Source: AIpwx486VRFRKB5/jYqC7qll4imVq7HhQTlnE/gquSaL6erpJArF2wfg5g9vLnhKhixWUN2QcdjCOjQfGM9MWLxMvsA= X-Received: by 2002:a9d:2a09:: with SMTP id t9-v6mr347200ota.392.1522777478799; Tue, 03 Apr 2018 10:44:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Tue, 3 Apr 2018 10:43:58 -0700 (PDT) In-Reply-To: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Tue, 3 Apr 2018 10:43:58 -0700 Message-ID: To: Ben Campbell Cc: Adam Roach , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , Peter Saint-Andre , draft-ietf-mmusic-trickle-ice-sip@ietf.org Content-Type: multipart/alternative; boundary="000000000000b2373e0568f54261" Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:00:22 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:44:48 -0000 --000000000000b2373e0568f54261 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell wrote: > > > > On Apr 3, 2018, at 12:26 PM, Eric Rescorla wrote: > > > > I don't think #3 is acceptable. AFAIK JSEP has no other dependencies on > SIP. If you think #2 and #3 are equally awkward, lets do #2. > > > > I said they are equally awkward (by which I mean equally awkward for > readers after publication), but 3 requires fewer changes (that is, less > effort.). > > If we want to go for least awkward, that probably means a separate > trickle-ice-sdp draft in parallel to the ice sdp draft. But that=E2=80=99= s the past > of most effort. > > But honestly, I think this is the sort of point that we should defer to W= G > consensus. > Which WG? As I understand it, this would require a change to JSEP, which would also require WG consensus, plus a change to an IESG-approved document= . -Ekr > Ben. > --000000000000b2373e0568f54261 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell <ben@nostrum.com> wrote:


> On Apr 3, 2018, at 12:26 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> I don't think #3 is acceptable. AFAIK JSEP has no other dependenci= es on SIP. If you think #2 and #3 are equally awkward, lets do #2.
>

I said they are equally awkward (by which I mean equally awkward for= readers after publication), but 3 requires fewer changes (that is, less ef= fort.).

If we want to go for least awkward, that probably means a separate trickle-= ice-sdp draft in parallel to the ice sdp draft. But that=E2=80=99s the past= of most effort.

But honestly, I think this is the sort of point that we should defer to WG = consensus.

Which WG? As I understand it= , this would require a change to JSEP, which would also require WG consensu= s, plus a change to an IESG-approved document.

-Ek= r


Ben.

--000000000000b2373e0568f54261-- From nobody Tue Apr 3 11:01:22 2018 Return-Path: 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 4B69812D7F8; Tue, 3 Apr 2018 10:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 4yXcPuXF7gTa; Tue, 3 Apr 2018 10:48:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4D21243F6; Tue, 3 Apr 2018 10:48:31 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w33HmQar090499 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Apr 2018 12:48:27 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Roman Shpount , Eric Rescorla Cc: Ben Campbell , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Tue, 3 Apr 2018 12:48:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6539FF7135EF8D048AB08991" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:00:22 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:48:33 -0000 This is a multi-part message in MIME format. --------------6539FF7135EF8D048AB08991 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/3/18 12:38 PM, Roman Shpount wrote: > Do you want to move all other trickle ICE specific SDP related changes > from  draft-ietf-mmusic-trickle-ice-sip to draft-ietf-mmusic-ice-sip-sdp? > > It is not just end-of-candidates, but also support for c=0.0.0.0 in > offers, SDP offers without the candidates, different mismatch rules. > As it stands, draft-ietf-mmusic-trickle-ice-sip changes how > draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used. To be clear, the other changes you cite are specific to SIP, as evidenced by the fact that JSEP does not need to make use of them. I don't see a major problem with moving them (other than it being make-work), but I also don't see any value in doing so. /a --------------6539FF7135EF8D048AB08991 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/3/18 12:38 PM, Roman Shpount wrote:
Do you want to move all other trickle ICE specific SDP related changes from  draft-ietf-mmusic-trickle-ice-sip to draft-ietf-mmusic-ice-sip-sdp?

It is not just end-of-candidates, but also support for c=0.0.0.0 in offers, SDP offers without the candidates, different mismatch rules. As it stands,  draft-ietf-mmusic-trickle-ice-sip changes how draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used.

To be clear, the other changes you cite are specific to SIP, as evidenced by the fact that JSEP does not need to make use of them. I don't see a major problem with moving them (other than it being make-work), but I also don't see any value in doing so.

/a
--------------6539FF7135EF8D048AB08991-- From nobody Tue Apr 3 11:01:28 2018 Return-Path: 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 CD566126D85; Tue, 3 Apr 2018 10:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 z4yZue13ztZg; Tue, 3 Apr 2018 10:54:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EA5126C83; Tue, 3 Apr 2018 10:54:24 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w33HsKvk091488 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Apr 2018 12:54:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_356BC256-487E-4960-9F0C-D1C83B302531"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 3 Apr 2018 12:54:19 -0500 In-Reply-To: Cc: Adam Roach , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , Peter Saint-Andre , draft-ietf-mmusic-trickle-ice-sip@ietf.org To: Eric Rescorla References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:00:22 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:54:27 -0000 --Apple-Mail=_356BC256-487E-4960-9F0C-D1C83B302531 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 3, 2018, at 12:43 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell wrote: >=20 >=20 > > On Apr 3, 2018, at 12:26 PM, Eric Rescorla wrote: > > > > I don't think #3 is acceptable. AFAIK JSEP has no other dependencies = on SIP. If you think #2 and #3 are equally awkward, lets do #2. > > >=20 > I said they are equally awkward (by which I mean equally awkward for = readers after publication), but 3 requires fewer changes (that is, less = effort.). >=20 > If we want to go for least awkward, that probably means a separate = trickle-ice-sdp draft in parallel to the ice sdp draft. But that=E2=80=99s= the past of most effort. >=20 > But honestly, I think this is the sort of point that we should defer = to WG consensus. >=20 > Which WG? As I understand it, this would require a change to JSEP, = which would also require WG consensus, plus a change to an IESG-approved = document. I mean consensus of the WGs producing the documents. it=E2=80=99s quite = reasonable for a dependent WG to offer feedback, but I don=E2=80=99t = think a dependent WG gets to just override that consensus. Ben. --Apple-Mail=_356BC256-487E-4960-9F0C-D1C83B302531 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrDv8sACgkQgFZKbJXz 1A0w/g/9Hwquq5N2mTLwnJjZi9HJvFeTAao2SfZmb3qGmvRb364h5tA7IxAS46ZU KKxUvPwMNY27rhromHvbkFLYpZS6xdet+hBxMDwhbcA7kK/FO1Hhf28emdCtXsob wCDUUwGmAeViVFztZhYy4kHiQIRw84oLP/bLXF1knEVVnHL3WHlxtW/WVcLMBszW yeA6SEafDQvu7pptq3ilEeAw4ytsp+TmwmsQfDz5kGZzxCPnS9I6uqmRI31uZUjz hT2d3rgVseiSO3Dh6ECSh+XNdDErA3kDai2iuwGHa9+HwllDZJLmSlK15Km32zz+ VOSvyp8Js05mND6VWRJFGAkTmAVhF3kz93ejBSRwP6a5t6s9o9szX+5VRNjRD0ce XjGp7d5l/jh2wmWtovjp7JR+u43ttFhtmMJ72KS72BsxCgkyI3JkOATGi4QroyiV QSEnXy/I0ULol1hDG5Cs5qZq9qJTEfwvOh04tOyANDW5cSDH6+9gK2iKhsvY9R8q tcm8vITjnTfVaRelaWORkUjxu1bUpUFYYotB3cAohFGIg1wcvVKH1HbXtuoHVG86 vXfXzDg4m3ghGISG77q9d48gzpjIVL3cAaYLVIIbGcKk/dXOuSxD+B4/eYORY/OJ e2gDmI8ywnqkPeC21odNOZlHT7y0O3F4klLv5cXTRwdu1YejmzE= =i+EF -----END PGP SIGNATURE----- --Apple-Mail=_356BC256-487E-4960-9F0C-D1C83B302531-- From nobody Tue Apr 3 11:11:49 2018 Return-Path: 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 5F73512EA62 for ; Tue, 3 Apr 2018 11:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 s6K904oO4J9t for ; Tue, 3 Apr 2018 11:00:49 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16C512EB00 for ; Tue, 3 Apr 2018 11:00:36 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id g20-v6so9890858plo.9 for ; Tue, 03 Apr 2018 11:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i6LuCc25YMYr+Q2zGRJr1vtPUSAl8OoFlkMt1XF4bzg=; b=GIm4wPBheeBE6SlPNCd6sKIwKo7tRZLTl2qKY6/ByymFbmtZS8vvMmI8A/+5ZGPAky 67Qxe+FQVlOvAiBxnGV3Exfu8qHgvbumlQCPg5LEcd5zAr3nZxWVdVQojWYd9fVWmFX9 /+SUxwDknVA0My+E9FeXRluyyz1xxJsAU6opo7EduA2SKzV3L6AvNm83L5vZW+assOKc U334mLDj/GA9eI4ZK8VluBBLD6uKfnQF/2+FZpWrcVV+GvEAe6m3v1C6VsTYXxZo/cqk aWuut9J5Om8fWrpzhIpZ5xaDZ4tv8Rt0DCElJtSoDjBicTUOIh/+ARSGKOinoJ2+s3Vu nSEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i6LuCc25YMYr+Q2zGRJr1vtPUSAl8OoFlkMt1XF4bzg=; b=Mwv6I0Tj5YaYLHllbK6qrzUEDAUKDmDuwWu7yPEYSs3GI+DLzo0x08bl8HuTdmKS9k jqmGu2KB82f6Z9VF9fc4KJZLqdRQhUM50pS0x10lvclEj23zUSbjzuHYCIkOQCgx/OIR /qR0E4q5OyTQ/yzN7ut2R8YLkLmXRKj23KEAqFeMqcXb0W1RiouVHK874pnRQZZRpPQp f/gGrX0Sk8W1g7tZ1PMimZ2mnNICB36Xlb5XLQNiZmP2iBz2ZgZcnU0mOXlXwLiScLnD 3A3iTchYS7xqTwb2izRLvwYX6r7b2X9+UxPGyH0tfTJHwgUuu58VGGg+rIZEDvP067kg IplQ== X-Gm-Message-State: AElRT7E15jreWAn/Hc3hOYB10eZxeHasFo8VsaXde+R0zs/DnRkocetw c/0pzGTY10J2SuVO26/PZOXzHw== X-Google-Smtp-Source: AIpwx4+zMAosxmlEf8IfhtdIj0DsuFrXZrKODEAVNXwKiSt0WBcAMeDYLPkTi7ITWQHWZ43Jl63qjw== X-Received: by 10.98.80.145 with SMTP id g17mr11361581pfj.71.1522778436576; Tue, 03 Apr 2018 11:00:36 -0700 (PDT) Received: from mail-pl0-f54.google.com (mail-pl0-f54.google.com. [209.85.160.54]) by smtp.gmail.com with ESMTPSA id 86sm7805956pfh.93.2018.04.03.11.00.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 11:00:36 -0700 (PDT) Received: by mail-pl0-f54.google.com with SMTP id g20-v6so9890785plo.9; Tue, 03 Apr 2018 11:00:35 -0700 (PDT) X-Received: by 2002:a17:902:8548:: with SMTP id d8-v6mr15506600plo.241.1522778435567; Tue, 03 Apr 2018 11:00:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.79 with HTTP; Tue, 3 Apr 2018 11:00:34 -0700 (PDT) In-Reply-To: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> From: Roman Shpount Date: Tue, 3 Apr 2018 14:00:34 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: Eric Rescorla , Ben Campbell , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org Content-Type: multipart/alternative; boundary="000000000000b948dd0568f57b39" Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:11:48 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:01:02 -0000 --000000000000b948dd0568f57b39 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 3, 2018 at 1:48 PM, Adam Roach wrote: > On 4/3/18 12:38 PM, Roman Shpount wrote: > > Do you want to move all other trickle ICE specific SDP related changes > from draft-ietf-mmusic-trickle-ice-sip to draft-ietf-mmusic-ice-sip-sdp? > > It is not just end-of-candidates, but also support for c=0.0.0.0 in > offers, SDP offers without the candidates, different mismatch rules. As it > stands, draft-ietf-mmusic-trickle-ice-sip changes how > draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used. > > > To be clear, the other changes you cite are specific to SIP, as evidenced > by the fact that JSEP does not need to make use of them. I don't see a > major problem with moving them (other than it being make-work), but I also > don't see any value in doing so. > All the things I have referenced are being used by JSEP. For instance current in draft-ietf-rtcweb-jsep-24 ( https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-5.2.1): If the m= section is marked as bundle-only, then the port value MUST be set to 0. Otherwise, the port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1. I am fairly sure this is no longer in ietf-ice-trickle and was moved to draft-ietf-mmusic-trickle-ice-sip ( https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-14#section-4.1.1 ). Regards, _____________ Roman Shpount --000000000000b948dd0568f57b39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 3, 2018 at 1:48 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 4/3/18 12= :38 PM, Roman Shpount wrote:
Do you want to move all other trickle ICE specific SDP related changes from =C2=A0draft-ietf-mmusic-trickle-ice-s= ip to draft-ietf-mmusic-ice-sip-sdp?

It is not just end-of-candidates, but also support for c=3D0.0.0.0 in offers, SDP offers without the candidates, different mismatch rules. As it stands,=C2=A0 draft-ietf-mmusic-trickle-ice-si= p=C2=A0changes how=C2=A0draft-ietf-mmusic-ice-sip-sdp=C2=A0works when trickle ICE is used.

 To be clear, the other changes you cite are specific to SIP, as evidenced by the fact that JSEP does not need to make use of them. I don't see a major problem with moving them (other than it being make-work), but I also don't see any value in doing so.

All the things I have referenced are being used = by JSEP.

For instance current in draft-ietf-rtcweb= -jsep-24 (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#sectio= n-5.2.1):

If the m=3D section is marked as bundle-only, then the port value MUST be s= et to 0.=C2=A0 Otherwise, the port value is set to the port of the default = ICE candidate for this m=3D section, but given that no candidates are avail= able yet, the "dummy" port value of 9 (Discard) MUST be used, as = indicated in [I-D.ietf-ice-trickle], Section 5.1. =C2=A0

I am fairly sure this i= s no longer in=20 ietf-ice-trickle=C2=A0 and was moved to dr= aft-ietf-mmusic-trickle-ice-sip (https://tools.ietf.org/htm= l/draft-ietf-mmusic-trickle-ice-sip-14#section-4.1.1).

Regards,
<= div class=3D"gmail_signature">_____________
Roman Shpount

--000000000000b948dd0568f57b39-- From nobody Tue Apr 3 11:11:53 2018 Return-Path: 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 79E4612D7F9; Tue, 3 Apr 2018 11:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 CyqCrLtLjaDo; Tue, 3 Apr 2018 11:04:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A2812EA42; Tue, 3 Apr 2018 11:03:38 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w33I3XsT093111 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Apr 2018 13:03:34 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Ben Campbell , Eric Rescorla Cc: mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , Peter Saint-Andre , draft-ietf-mmusic-trickle-ice-sip@ietf.org References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> Date: Tue, 3 Apr 2018 13:03:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:11:48 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:04:21 -0000 On 4/3/18 12:54 PM, Ben Campbell wrote: > >> On Apr 3, 2018, at 12:43 PM, Eric Rescorla wrote: >> >> >> >> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell wrote: >> >> >>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla wrote: >>> >>> I don't think #3 is acceptable. AFAIK JSEP has no other dependencies on SIP. If you think #2 and #3 are equally awkward, lets do #2. >>> >> I said they are equally awkward (by which I mean equally awkward for readers after publication), but 3 requires fewer changes (that is, less effort.). >> >> If we want to go for least awkward, that probably means a separate trickle-ice-sdp draft in parallel to the ice sdp draft. But that’s the past of most effort. >> >> But honestly, I think this is the sort of point that we should defer to WG consensus. >> >> Which WG? As I understand it, this would require a change to JSEP, which would also require WG consensus, plus a change to an IESG-approved document. > > I mean consensus of the WGs producing the documents. it’s quite reasonable for a dependent WG to offer feedback, but I don’t think a dependent WG gets to just override that consensus. I don't think it's as clean cut as that. JSEP could have defined the "a=end-of-candidates" syntax, and certainly would have if MMUSIC and ICE had pulled it out of their documents. But I don't think we want both documents independently registering identical syntaxes with identical meanings, right? Or I suppose JSEP could have decided -- having finished first -- that they should define the syntax and have the trickle-ice-sip document reference JSEP? I'm offering those up as examples, not proposals. I think the first is a nonstarter, and the second is... well, it's as awkward as what you're proposing. I'm beginning to think we need to to take the question to ART rather than the three working groups. /a From nobody Tue Apr 3 11:23:35 2018 Return-Path: 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 BF46012E8A4; Tue, 3 Apr 2018 11:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 01xH36K864T8; Tue, 3 Apr 2018 11:22:11 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29ECB12D80E; Tue, 3 Apr 2018 11:22:11 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id l21so11627968uak.1; Tue, 03 Apr 2018 11:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jk7EvySYIjrC1R635lzoIDDuJcckB/u7zCl84MxPMic=; b=RH5wwDnBXZg+PXJexS9ZDuzHybId2y0guLUXGW9xVbQTWj52+2jJB7j9AGhLXARVXk yH0f23x+eV9cZlGuulxEjWT+NrFes20dC0bzo/HPv40FmLncT6GDPcT/74HsQbE7wRGE dPc3B1iVUiAj/QeoGuc3rNkmVNiP1NU+AKtlZ8QYAB9LEE0diNOTZ2nAeOOLC6LTQGv1 kKeQsgLDUr7Qr/KBc6Pk4mqpPx4IjE2tPTBhmiipe7i1DB1RiyFd/8NIYd6V5lEzW1/b v5Vt4FmBddXSNWVFrvnd4r6kedE6wCkpMR0Jm+qQ2kj1GgwVK8hAsx/nxaYt0mX52/uk f2Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jk7EvySYIjrC1R635lzoIDDuJcckB/u7zCl84MxPMic=; b=HxXKAZcPNppqQYmyUc/76e3MQq3GOY2n0T3VXQqUVcTGkZrzyPpmupu4Dbf9yuoAUN fph+c3068/69gFOQoQGWDwokI+i5lkOvhpldp52mmKPm3tRm79lG7qf2MnB1selODYKE RtlLu6rGOPGk4KpBPk2JzRFH0QONRgGoxV11iu+PHx7wLCX0b6DRHSLPZq/px1IXJhL9 Vl7uBo4mrhPdDaf/fxxlmHbKPNGIV2wR/2O77yDg2XGe1VCiri+PJFRMxRwwgJOSLpfB kgshensN4o/hlwAhvMKii/kweNX/9p/6UVqSspQMZ4FHzwJl4cQr4cPy9KYEBXNxP9Ro 240w== X-Gm-Message-State: ALQs6tAdLwrLMtMMChTOzXRVPOlcPMKyNPR3+dmVDp5w2i6fD9axw7ry eTgujyCMZJWZrtlUW2EccjTeqfkNaFUKMFSjvpI= X-Google-Smtp-Source: AIpwx49LVGOYABrhIKSHIbUgv+7WT4uTh5z1B88dNHPoIEk3IxRukhqacXCMUhuRIr+YJKJmYW2lP//irgdHepKUl+A= X-Received: by 10.159.55.104 with SMTP id a37mr9002406uae.11.1522779730112; Tue, 03 Apr 2018 11:22:10 -0700 (PDT) MIME-Version: 1.0 References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> In-Reply-To: <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> From: Suhas Nandakumar Date: Tue, 03 Apr 2018 18:21:59 +0000 Message-ID: To: Adam Roach Cc: Ben Campbell , Eric Rescorla , Flemming Andreasen , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org, "ice@ietf.org" , mmusic WG , mmusic-chairs@ietf.org, "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a114067bee275610568f5c854" Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:23:33 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:22:15 -0000 --001a114067bee275610568f5c854 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adding a data point Icebis doesn=E2=80=99t talk about trickle ice and hence ice-sip-SDP doesn= =E2=80=99t either. In the same context, would ice trickle and ice-trickle-sip-SDP focussing on trickle ice only procedures and usages makes sense ? Does that work ? On Tue, Apr 3, 2018 at 11:04 AM Adam Roach wrote: > On 4/3/18 12:54 PM, Ben Campbell wrote: > > > >> On Apr 3, 2018, at 12:43 PM, Eric Rescorla wrote: > >> > >> > >> > >> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell wrote: > >> > >> > >>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla wrote: > >>> > >>> I don't think #3 is acceptable. AFAIK JSEP has no other dependencies > on SIP. If you think #2 and #3 are equally awkward, lets do #2. > >>> > >> I said they are equally awkward (by which I mean equally awkward for > readers after publication), but 3 requires fewer changes (that is, less > effort.). > >> > >> If we want to go for least awkward, that probably means a separate > trickle-ice-sdp draft in parallel to the ice sdp draft. But that=E2=80=99= s the past > of most effort. > >> > >> But honestly, I think this is the sort of point that we should defer t= o > WG consensus. > >> > >> Which WG? As I understand it, this would require a change to JSEP, > which would also require WG consensus, plus a change to an IESG-approved > document. > > > > I mean consensus of the WGs producing the documents. it=E2=80=99s quite > reasonable for a dependent WG to offer feedback, but I don=E2=80=99t thin= k a > dependent WG gets to just override that consensus. > > I don't think it's as clean cut as that. JSEP could have defined the > "a=3Dend-of-candidates" syntax, and certainly would have if MMUSIC and IC= E > had pulled it out of their documents. But I don't think we want both > documents independently registering identical syntaxes with identical > meanings, right? Or I suppose JSEP could have decided -- having finished > first -- that they should define the syntax and have the trickle-ice-sip > document reference JSEP? > > I'm offering those up as examples, not proposals. I think the first is a > nonstarter, and the second is... well, it's as awkward as what you're > proposing. > > I'm beginning to think we need to to take the question to ART rather > than the three working groups. > > /a > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a114067bee275610568f5c854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adding a data point=C2=A0
Icebis doesn=E2=80=99t talk about trickle ice and = hence ice-sip-SDP doesn=E2=80=99t either.

=
In the same context, would ice trickle and ice-trickle-si= p-SDP focussing on trickle ice only procedures and usages makes sense ?


Does that work ?=C2=A0


On Tue, Apr 3, 2018 at 11:04 AM Adam Roach <adam@nostrum.com> wrote:
On 4/3/18 12:54 PM, Ben Campbell wrote:
>
>> On Apr 3, 2018, at 12:43 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>
>>
>> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell <ben@nostrum.com> wrote:
>>
>>
>>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>> I don't think #3 is acceptable. AFAIK JSEP has no other de= pendencies on SIP. If you think #2 and #3 are equally awkward, lets do #2.<= br> >>>
>> I said they are equally awkward (by which I mean equally awkward f= or readers after publication), but 3 requires fewer changes (that is, less = effort.).
>>
>> If we want to go for least awkward, that probably means a separate= trickle-ice-sdp draft in parallel to the ice sdp draft. But that=E2=80=99s= the past of most effort.
>>
>> But honestly, I think this is the sort of point that we should def= er to WG consensus.
>>
>> Which WG? As I understand it, this would require a change to JSEP,= which would also require WG consensus, plus a change to an IESG-approved d= ocument.
>
> I mean consensus of the WGs producing the documents. it=E2=80=99s quit= e reasonable for a dependent WG to offer feedback, but I don=E2=80=99t thin= k a dependent WG gets to just override that consensus.

I don't think it's as clean cut as that. JSEP could have defined th= e
"a=3Dend-of-candidates" syntax, and certainly would have if MMUSI= C and ICE
had pulled it out of their documents. But I don't think we want both documents independently registering identical syntaxes with identical
meanings, right? Or I suppose JSEP could have decided -- having finished first -- that they should define the syntax and have the trickle-ice-sip document reference JSEP?

I'm offering those up as examples, not proposals. I think the first is = a
nonstarter, and the second is... well, it's as awkward as what you'= re
proposing.

I'm beginning to think we need to to take the question to ART rather than the three working groups.

/a

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--001a114067bee275610568f5c854-- From nobody Tue Apr 3 11:30:35 2018 Return-Path: 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 1071612D7F7; Tue, 3 Apr 2018 11:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jvAiV84Dx8hM; Tue, 3 Apr 2018 11:28:10 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405E7124BE8; Tue, 3 Apr 2018 11:28:10 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id n64so7626343vkf.12; Tue, 03 Apr 2018 11:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mysX+mSoNWlATAiKXpXaPKWd5hqPtiQnD7wj1XB4yo4=; b=an2bBKk0BRZFAy2/roizruZOrQjOCgyQjdZe+BDPSVJ4bg7g/K9zv7AFtdYm1xg7yZ XcLfLzCOg5wnt7ycFNyGPMfUv/R+/90x4z4V25x698LJujOf1xXHIFSgWi9xYAp7BX/Y bQW3CoG3JZGp7jn8bhOXmq+u52tAai2z3CGd2JSjc9iPzexQrw0llTOJrFpRcY+yMIh7 AyNVKzicGOXlu+u1ujx1+Hf9Ra9L5VpQgKev1yxE5CfYKiwIj5EefUOmvR+TGJlsmmY3 XDfKLwFORcVK4Y3HQruXGnL+d6AJYVMMmV0yxWMQ9yEeN13wiHfQ3Qi4nb4RHzqCyNZc WZhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mysX+mSoNWlATAiKXpXaPKWd5hqPtiQnD7wj1XB4yo4=; b=LjWLMJ6QFqtMWoY8t+aungW56Qe01I/GJ9ojO5GDp7LYFG8xgjjZjsFgSxcI4hnAN6 PUsqeCzhz/2Crj8sLR4K+FQdbslIuadZG/3btb5JE79Q6BIir2CXS2eKbrfKJ/Ho5aLE dZzgybVAPI7kXr2Ec7f5ItBmBMlZNXmEk1neBS0TxejUTWBXhvZh73I5WYqrUchgDzzP 7zD1gVNhVsRZqZlf18hpp6I6CDoYqJOZd+jLN258MbbAgsPstEWsY2S129esQ/I3o7Mr zw3zrzwHCCk0CSQpzfScZLStoFAdi1vKj7w/dkJK0+ExWD6lx/58QH6kCb0imzQEFGcu NY4A== X-Gm-Message-State: ALQs6tDxz95Oi6V9DGRUIxJIly6IDFZYn+C3S3bap7JLociyRcbR06fp xFZVw06ryz/KXBFRxnspV8Jt5tTdGHBl3pTb/P0= X-Google-Smtp-Source: AIpwx49u6PwQ36oLkpL2BOo+NXAZBUoNiSBFCaTpNPMhY6fLL3HBeoXNBdXH/dlAPXqiFfMw6ATPlyrWuaHLPIrcz4U= X-Received: by 10.31.174.80 with SMTP id x77mr8595019vke.101.1522780089273; Tue, 03 Apr 2018 11:28:09 -0700 (PDT) MIME-Version: 1.0 References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> In-Reply-To: From: Suhas Nandakumar Date: Tue, 03 Apr 2018 18:27:58 +0000 Message-ID: To: Adam Roach Cc: Ben Campbell , Eric Rescorla , Flemming Andreasen , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org, "ice@ietf.org" , mmusic WG , mmusic-chairs@ietf.org, "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a1143fa3a4ad2460568f5de4e" Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:30:33 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:28:13 -0000 --001a1143fa3a4ad2460568f5de4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to complete, ice-bis doesn=E2=80=99t normatively reference ice-sip-SDP= draft when it moved to using =E2=80=9Cusages =E2=80=9C indirections for signaling= protocols. Trickle ice can use similar approach and refer to trickle-sip as usage for trickle. Thanks Suhas On Tue, Apr 3, 2018 at 11:21 AM Suhas Nandakumar wrote: > Adding a data point > > Icebis doesn=E2=80=99t talk about trickle ice and hence ice-sip-SDP doesn= =E2=80=99t either. > > In the same context, would ice trickle and ice-trickle-sip-SDP focussing > on trickle ice only procedures and usages makes sense ? > > > Does that work ? > > > On Tue, Apr 3, 2018 at 11:04 AM Adam Roach wrote: > >> On 4/3/18 12:54 PM, Ben Campbell wrote: >> > >> >> On Apr 3, 2018, at 12:43 PM, Eric Rescorla wrote: >> >> >> >> >> >> >> >> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell wrote= : >> >> >> >> >> >>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla wrote: >> >>> >> >>> I don't think #3 is acceptable. AFAIK JSEP has no other dependencies >> on SIP. If you think #2 and #3 are equally awkward, lets do #2. >> >>> >> >> I said they are equally awkward (by which I mean equally awkward for >> readers after publication), but 3 requires fewer changes (that is, less >> effort.). >> >> >> >> If we want to go for least awkward, that probably means a separate >> trickle-ice-sdp draft in parallel to the ice sdp draft. But that=E2=80= =99s the past >> of most effort. >> >> >> >> But honestly, I think this is the sort of point that we should defer >> to WG consensus. >> >> >> >> Which WG? As I understand it, this would require a change to JSEP, >> which would also require WG consensus, plus a change to an IESG-approved >> document. >> > >> > I mean consensus of the WGs producing the documents. it=E2=80=99s quit= e >> reasonable for a dependent WG to offer feedback, but I don=E2=80=99t thi= nk a >> dependent WG gets to just override that consensus. >> >> I don't think it's as clean cut as that. JSEP could have defined the >> "a=3Dend-of-candidates" syntax, and certainly would have if MMUSIC and I= CE >> had pulled it out of their documents. But I don't think we want both >> documents independently registering identical syntaxes with identical >> meanings, right? Or I suppose JSEP could have decided -- having finished >> first -- that they should define the syntax and have the trickle-ice-sip >> document reference JSEP? >> >> I'm offering those up as examples, not proposals. I think the first is a >> nonstarter, and the second is... well, it's as awkward as what you're >> proposing. >> >> I'm beginning to think we need to to take the question to ART rather >> than the three working groups. >> >> /a >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > --001a1143fa3a4ad2460568f5de4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to complete, ice-bis doesn=E2=80=99t normativel= y reference ice-sip-SDP draft when it moved to using =E2=80=9Cusages =E2=80= =9C indirections for signaling protocols.

=

Trickle ice can use similar a= pproach and refer to trickle-sip as usage for trickle.

Thanks
Suhas=C2=A0
On Tue, Apr 3, 2018 at 11:21 AM Suha= s Nandakumar <suhasietf@gmail.com= > wrote:
Adding a data point=C2=A0

Icebis doesn=E2=80=99t talk about trickle ice and hence ice-sip-SDP d= oesn=E2=80=99t either.

I= n the same context, would ice trickle and ice-trickle-sip-SDP focussing on = trickle ice only procedures and usages makes sense ?


Does that work ?= =C2=A0


On Tue, Apr 3, 2018 at 11:04 AM Adam Roach <adam@nostrum.com> wrote:
On 4/3/18 12:54 PM, Ben Campbell wrote:<= br> >
>> On Apr 3, 2018, at 12:43 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>
>>
>> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell <ben@nostrum.com> wrote:
>>
>>
>>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>> I don't think #3 is acceptable. AFAIK JSEP has no other de= pendencies on SIP. If you think #2 and #3 are equally awkward, lets do #2.<= br> >>>
>> I said they are equally awkward (by which I mean equally awkward f= or readers after publication), but 3 requires fewer changes (that is, less = effort.).
>>
>> If we want to go for least awkward, that probably means a separate= trickle-ice-sdp draft in parallel to the ice sdp draft. But that=E2=80=99s= the past of most effort.
>>
>> But honestly, I think this is the sort of point that we should def= er to WG consensus.
>>
>> Which WG? As I understand it, this would require a change to JSEP,= which would also require WG consensus, plus a change to an IESG-approved d= ocument.
>
> I mean consensus of the WGs producing the documents. it=E2=80=99s quit= e reasonable for a dependent WG to offer feedback, but I don=E2=80=99t thin= k a dependent WG gets to just override that consensus.

I don't think it's as clean cut as that. JSEP could have defined th= e
"a=3Dend-of-candidates" syntax, and certainly would have if MMUSI= C and ICE
had pulled it out of their documents. But I don't think we want both documents independently registering identical syntaxes with identical
meanings, right? Or I suppose JSEP could have decided -- having finished first -- that they should define the syntax and have the trickle-ice-sip document reference JSEP?

I'm offering those up as examples, not proposals. I think the first is = a
nonstarter, and the second is... well, it's as awkward as what you'= re
proposing.

I'm beginning to think we need to to take the question to ART rather than the three working groups.

/a

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--001a1143fa3a4ad2460568f5de4e-- From nobody Tue Apr 3 11:30:40 2018 Return-Path: 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 F008612EA5A; Tue, 3 Apr 2018 11:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 B2mgxobLuAWH; Tue, 3 Apr 2018 11:29:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092AD12EA87; Tue, 3 Apr 2018 11:29:08 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w33IT1bn097356 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Apr 2018 13:29:02 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Suhas Nandakumar Cc: Ben Campbell , Eric Rescorla , Flemming Andreasen , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org, "ice@ietf.org" , mmusic WG , mmusic-chairs@ietf.org, "rtcweb@ietf.org" References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> From: Adam Roach Message-ID: <0503b397-787a-a0de-15aa-dc6dee57a4f8@nostrum.com> Date: Tue, 3 Apr 2018 13:28:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F126C25807B9208D48B05CB1" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 11:30:33 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:29:23 -0000 This is a multi-part message in MIME format. --------------F126C25807B9208D48B05CB1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Like I said originally, none of these are particularly clean. Your proposal points towards either #1 or #3, and I highlighted their drawbacks in my original message. Fundamentally, the suggestion Ben made is the only clean one: split trickle-ice-sip into two documents: one deals with SIP (think a parallel to RFC 3261) while the other deals with SDP (think a parallel to RFC 3264). But I also agree with him that sending the document back to the WG for such a split would introduce a significant amount of work. Absent that, we need to pick which wart we're going to accept. /a On 4/3/18 1:21 PM, Suhas Nandakumar wrote: > Adding a data point > > Icebis doesn’t talk about trickle ice and hence ice-sip-SDP doesn’t > either. > > In the same context, would ice trickle and ice-trickle-sip-SDP > focussing on trickle ice only procedures and usages makes sense ? > > > Does that work ? > > > On Tue, Apr 3, 2018 at 11:04 AM Adam Roach > wrote: > > On 4/3/18 12:54 PM, Ben Campbell wrote: > > > >> On Apr 3, 2018, at 12:43 PM, Eric Rescorla > wrote: > >> > >> > >> > >> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell > wrote: > >> > >> > >>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla > wrote: > >>> > >>> I don't think #3 is acceptable. AFAIK JSEP has no other > dependencies on SIP. If you think #2 and #3 are equally awkward, > lets do #2. > >>> > >> I said they are equally awkward (by which I mean equally > awkward for readers after publication), but 3 requires fewer > changes (that is, less effort.). > >> > >> If we want to go for least awkward, that probably means a > separate trickle-ice-sdp draft in parallel to the ice sdp draft. > But that’s the past of most effort. > >> > >> But honestly, I think this is the sort of point that we should > defer to WG consensus. > >> > >> Which WG? As I understand it, this would require a change to > JSEP, which would also require WG consensus, plus a change to an > IESG-approved document. > > > > I mean consensus of the WGs producing the documents. it’s quite > reasonable for a dependent WG to offer feedback, but I don’t think > a dependent WG gets to just override that consensus. > > I don't think it's as clean cut as that. JSEP could have defined the > "a=end-of-candidates" syntax, and certainly would have if MMUSIC > and ICE > had pulled it out of their documents. But I don't think we want both > documents independently registering identical syntaxes with identical > meanings, right? Or I suppose JSEP could have decided -- having > finished > first -- that they should define the syntax and have the > trickle-ice-sip > document reference JSEP? > > I'm offering those up as examples, not proposals. I think the > first is a > nonstarter, and the second is... well, it's as awkward as what you're > proposing. > > I'm beginning to think we need to to take the question to ART rather > than the three working groups. > > /a > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------F126C25807B9208D48B05CB1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Like I said originally, none of these are particularly clean. Your proposal points towards either #1 or #3, and I highlighted their drawbacks in my original message.

Fundamentally, the suggestion Ben made is the only clean one: split trickle-ice-sip into two documents: one deals with SIP (think a parallel to RFC 3261) while the other deals with SDP (think a parallel to RFC 3264). But I also agree with him that sending the document back to the WG for such a split would introduce a significant amount of work.

Absent that, we need to pick which wart we're going to accept.

/a

On 4/3/18 1:21 PM, Suhas Nandakumar wrote:
Adding a data point 

Icebis doesn’t talk about trickle ice and hence ice-sip-SDP doesn’t either.

In the same context, would ice trickle and ice-trickle-sip-SDP focussing on trickle ice only procedures and usages makes sense ?


Does that work ? 


On Tue, Apr 3, 2018 at 11:04 AM Adam Roach <adam@nostrum.com> wrote:
On 4/3/18 12:54 PM, Ben Campbell wrote:
>
>> On Apr 3, 2018, at 12:43 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>
>>
>> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell <ben@nostrum.com> wrote:
>>
>>
>>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>> I don't think #3 is acceptable. AFAIK JSEP has no other dependencies on SIP. If you think #2 and #3 are equally awkward, lets do #2.
>>>
>> I said they are equally awkward (by which I mean equally awkward for readers after publication), but 3 requires fewer changes (that is, less effort.).
>>
>> If we want to go for least awkward, that probably means a separate trickle-ice-sdp draft in parallel to the ice sdp draft. But that’s the past of most effort.
>>
>> But honestly, I think this is the sort of point that we should defer to WG consensus.
>>
>> Which WG? As I understand it, this would require a change to JSEP, which would also require WG consensus, plus a change to an IESG-approved document.
>
> I mean consensus of the WGs producing the documents. it’s quite reasonable for a dependent WG to offer feedback, but I don’t think a dependent WG gets to just override that consensus.

I don't think it's as clean cut as that. JSEP could have defined the
"a=end-of-candidates" syntax, and certainly would have if MMUSIC and ICE
had pulled it out of their documents. But I don't think we want both
documents independently registering identical syntaxes with identical
meanings, right? Or I suppose JSEP could have decided -- having finished
first -- that they should define the syntax and have the trickle-ice-sip
document reference JSEP?

I'm offering those up as examples, not proposals. I think the first is a
nonstarter, and the second is... well, it's as awkward as what you're
proposing.

I'm beginning to think we need to to take the question to ART rather
than the three working groups.

/a

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--------------F126C25807B9208D48B05CB1-- From nobody Tue Apr 3 13:42:00 2018 Return-Path: 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 4759412EAC0 for ; Tue, 3 Apr 2018 11:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 VUshkJlpT-pz for ; Tue, 3 Apr 2018 11:39:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 AD4DB126E64 for ; Tue, 3 Apr 2018 11:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522780791; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=66tWBZRNlTx7cAjqhDh0S2oFq22lcKHRFI7hDKVIkNk=; b=URDp+6DgYzyj9dRIxaYW+Q9Sp1tIROkIQnD6VWMDrXuACQcIC3jBivmBmNHNS8nw saKnRkkvXmo16WdA/mdtPjlMGLfwjq94ahI6vjosewXDxZirbb3DhAoSsEKMdkBD C7Gcuz4VtSeoXVITDw0YZPf78LSaTcAO6xJeOevohmk=; X-AuditID: c1b4fb25-1dfff7000000522b-ed-5ac3ca776171 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 91.9B.21035.77AC3CA5; Tue, 3 Apr 2018 20:39:51 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Tue, 3 Apr 2018 20:39:51 +0200 From: Christer Holmberg To: Adam Roach , Ben Campbell , "Eric Rescorla" CC: mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , Peter Saint-Andre , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAAJqMw Date: Tue, 3 Apr 2018 18:39:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E43E23@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> In-Reply-To: <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7tG75qcNRBvOeaFjs+buI3WJ+52l2 ix9rlzNbrHh9jt3i/QVdi28Xai1m/JnIbHF+53omi6nLH7NYrP3Xzm7xbOUpRgdujym/N7J6 LFnyk8mj70AXq8esnU9YPCY/bmMOYI3isklJzcksSy3St0vgyrjz9jJLwQbOip7dF9gaGCdw djFyckgImEhcX3acFcQWEjjCKPHpVCGEvZhRYuchny5GDg42AQuJ7n/aIGERgWSJ9Rva2LsY uTiYBZ4zSdw8/4kdJCEsUCCxcU4rG0RRocTaHY+g7CiJyYufs4DYLAIqEjN7jjOC2LwCvhIz Fu1hAxkkJDCTRWLS6ltgDZwC9hL9a7eCNTAKiEl8P7WGCcRmFhCXuPVkPhPE0QISS/acZ4aw RSVePv7HCmErSTz9v4QJ5GhmAU2J9bv0IVoVJaZ0P2SH2CsocXLmE5YJjKKzkEydhdAxC0nH LCQdCxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExuXBLb9VdzBefuN4iFGAg1GJh9fp 6OEoIdbEsuLK3EOMEhzMSiK8CpuBQrwpiZVVqUX58UWlOanFhxilOViUxHkfmm+OEhJITyxJ zU5NLUgtgskycXBKNTC62HBnhYv1RHT/XtHT35LK2XbYIn5JVVpZ0aZwiWUm5se2fnH0eDQ/ upst3jnikPr89PLvDNbTzvcyfngsKcC9rHAhE3+enbV9DeeBnOaZ/otWnvRf4uSwQjrC7vPk lnVTZiWmdjFMZ7rTNWXysovebfN4lIM6Q249VmXvflX5/Gm2d7ygnxJLcUaioRZzUXEiAJdK /afHAgAA Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 13:41:48 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:40:03 -0000 SGksDQoNCj4gSSBkb24ndCB0aGluayBpdCdzIGFzIGNsZWFuIGN1dCBhcyB0aGF0LiBKU0VQIGNv dWxkIGhhdmUgZGVmaW5lZCB0aGUgImE9ZW5kLW9mLWNhbmRpZGF0ZXMiIHN5bnRheCwgYW5kIGNl cnRhaW5seSANCj4gd291bGQgaGF2ZSBpZiBNTVVTSUMgYW5kIElDRSBoYWQgcHVsbGVkIGl0IG91 dCBvZiB0aGVpciBkb2N1bWVudHMuIEJ1dCBJIGRvbid0IHRoaW5rIHdlIHdhbnQgYm90aCBkb2N1 bWVudHMgDQo+IGluZGVwZW5kZW50bHkgcmVnaXN0ZXJpbmcgaWRlbnRpY2FsIHN5bnRheGVzIHdp dGggaWRlbnRpY2FsIG1lYW5pbmdzLCByaWdodD8gT3IgSSBzdXBwb3NlIEpTRVAgY291bGQgaGF2 ZSBkZWNpZGVkIA0KPiAtLSBoYXZpbmcgZmluaXNoZWQgZmlyc3QgLS0gdGhhdCB0aGV5IHNob3Vs ZCBkZWZpbmUgdGhlIHN5bnRheCBhbmQgaGF2ZSB0aGUgdHJpY2tsZS1pY2Utc2lwIGRvY3VtZW50 IHJlZmVyZW5jZSBKU0VQPw0KPg0KPiBJJ20gb2ZmZXJpbmcgdGhvc2UgdXAgYXMgZXhhbXBsZXMs IG5vdCBwcm9wb3NhbHMuIEkgdGhpbmsgdGhlIGZpcnN0IGlzIGEgbm9uc3RhcnRlciwgYW5kIHRo ZSBzZWNvbmQgaXMuLi4gd2VsbCwgaXQncyBhcyANCj4gYXdrd2FyZCBhcyB3aGF0IHlvdSdyZSBw cm9wb3NpbmcuDQoNCkhhdmluZyB0cmlja2xlLWljZS1zaXAgcmVmZXJlbmNpbmcgSlNFUCwganVz dCBmb3IgdGhlIGF0dHJpYnV0ZSwgd291bGQgYmUgZXZlbiBtb3JlIGF3a3dhcmQgaW4gbXkgb3Bp bmlvbiA6KSANCg0KSW4gYWRkaXRpb24sIHdlIHdvdWxkIGFsc28gaGF2ZSB0byBhZGQgdGhlIGdl bmVyaWMgTy9BIHByb2NlZHVyZXMgZm9yIHRoZSBhdHRyaWJ1dGUgdG8gSlNFUC4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KDQo= From nobody Tue Apr 3 13:42:06 2018 Return-Path: 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 ADF7012EAB3 for ; Tue, 3 Apr 2018 11:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 lPc0BQAYMs7O for ; Tue, 3 Apr 2018 11:43:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 32E1712EA59 for ; Tue, 3 Apr 2018 11:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522781029; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=f1Dh/dTp8PHYPdzmIEhGrJ318h9S8Op9Q1EmdeBAOOw=; b=gonY3+gx8XU3Uo4Jcmmd+4jK/rfvU59Np1r+TXkyEvJY8E677z+wBuDMp6JApLjS ejyHCTk8aUu2cfk/S8bEeLfbwsrVz94T4AjTlJK0BqSfnT4Vs2+u0T+UwrfgTXpp kRLTh2I8rIhdnTYOS2maypExyjW09zGGNq7BPKgolBI=; X-AuditID: c1b4fb25-5a75a9c00000522b-2a-5ac3cb65703a Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.FB.21035.56BC3CA5; Tue, 3 Apr 2018 20:43:49 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0382.000; Tue, 3 Apr 2018 20:43:09 +0200 From: Christer Holmberg To: Adam Roach , Suhas Nandakumar CC: Ben Campbell , Eric Rescorla , "Flemming Andreasen" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "ice@ietf.org" , mmusic WG , "mmusic-chairs@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAAB8QCAACT40A== Date: Tue, 3 Apr 2018 18:43:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E43E90@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <0503b397-787a-a0de-15aa-dc6dee57a4f8@nostrum.com> In-Reply-To: <0503b397-787a-a0de-15aa-dc6dee57a4f8@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.162] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72E43E90ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUyM2K7vW7q6cNRBt8btSz2/F3EbjG/8zS7 xY+1y5ktVrw+x27x/oKuxbcLtRYz/kxktji/cz2TxdTlj1ks1v5rZ7fYObeD2YHbY8rvjawe O2fdZfdYsuQnk8esnU9YPCY/bmMOYI3isklJzcksSy3St0vgyph6ayNzwaVGxoo7iw8wNTBO qeti5OSQEDCRmPbpBVsXIxeHkMARRomWk83MEM5iRon9xz4AORwcbAIWEt3/tEFMEQFPidOz lEFKmAX+MUks37CdCWSQsECBxMY5rWwgtohAocTaHY+g7CyJhgOnmEFsFgEVie7fK9hBbF4B X4l9vz8wQuyayipxuOMlI8gCTgF7iS8LdEBqGAXEJL6fWgM2n1lAXOLWk/lMEEcLSCzZc54Z whaVePn4HyuErSTx9P8SqPp8iaM7TjBC7BKUODnzCcsERpFZSEbNQlI2C0nZLKArmAU0Jdbv 0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMBYPrjl t+oOxstvHA8xCnAwKvHwOh09HCXEmlhWXJl7iFGCg1lJhFdhM1CINyWxsiq1KD++qDQntfgQ ozQHi5I470PzzVFCAumJJanZqakFqUUwWSYOTqkGxog7l/a13t7Ufevie//7BXYb1hpULu5Z 6vupbG2MUvxBUzXpx6clGJmvb5pW9Cz66cETzB9/JN7jTVhmEpbYYvWk8P+RuPRNZ1NLX3l5 TNi0kX1T9Ms3kqW9Cw4aeXHk5PNMUfh+2ua6QvN53jsXPD9ZZc/R8ttx3uXbAuMk3u9hyif3 1Ok92qvEUpyRaKjFXFScCAD0LJTZ4QIAAA== Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 13:41:48 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 18:44:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B72E43E90ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5MaWtlIEkgc2FpZCBvcmlnaW5hbGx5LCBub25lIG9mIHRoZXNlIGFyZSBwYXJ0aWN1 bGFybHkgY2xlYW4uIFlvdXIgcHJvcG9zYWwgcG9pbnRzIHRvd2FyZHMgZWl0aGVyICMxIG9yICMz LCBhbmQNCj5JIGhpZ2hsaWdodGVkIHRoZWlyIGRyYXdiYWNrcyBpbiBteSBvcmlnaW5hbCBtZXNz YWdlLg0KPg0KPkZ1bmRhbWVudGFsbHksIHRoZSBzdWdnZXN0aW9uIEJlbiBtYWRlIGlzIHRoZSBv bmx5IGNsZWFuIG9uZTogc3BsaXQgdHJpY2tsZS1pY2Utc2lwIGludG8gdHdvIGRvY3VtZW50czog b25lIGRlYWxzIHdpdGggU0lQICh0aGluayBhIHBhcmFsbGVsIHRvIFJGQyAzMjYxKSA+d2hpbGUg dGhlIG90aGVyIGRlYWxzIHdpdGggU0RQICh0aGluayBhIHBhcmFsbGVsIHRvIFJGQyAzMjY0KS4g QnV0IEkgYWxzbyBhZ3JlZSB3aXRoIGhpbSB0aGF0IHNlbmRpbmcgdGhlIGRvY3VtZW50IGJhY2sg dG8gdGhlIFdHIGZvciBzdWNoIGEgc3BsaXQgd291bGQgPmludHJvZHVjZSBhIHNpZ25pZmljYW50 IGFtb3VudCBvZiB3b3JrLg0KDQpOb3QgZXhhY3RseSBzdXJlIHdoYXQg4oCcZGVhbHMgd2l0aCBT RFDigJ0gd291bGQgbWVhbiwgYnV0IG9uZSBpZGVhIHdvdWxkIGJlIHRvIE9OTFkgZGVmaW5lIHRo ZSBhdHRyaWJ1dGUsIGFuZCB0aGUgYXNzb2NpYXRlZCBPL0EgcHJvY2VkdXJlcywgaW4gYSBzZXBh cmF0ZSBkcmFmdCwgdGhhdCB3b3VsZCBiZSByZWZlcmVuY2VkIGJ5IGRyYWZ0LWlldGYtbW11c2lj LXRyaWNrbGUtaWNlLXNpcCBhbmQgSlNFUC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpP biA0LzMvMTggMToyMSBQTSwgU3VoYXMgTmFuZGFrdW1hciB3cm90ZToNCkFkZGluZyBhIGRhdGEg cG9pbnQNCg0KSWNlYmlzIGRvZXNu4oCZdCB0YWxrIGFib3V0IHRyaWNrbGUgaWNlIGFuZCBoZW5j ZSBpY2Utc2lwLVNEUCBkb2VzbuKAmXQgZWl0aGVyLg0KDQpJbiB0aGUgc2FtZSBjb250ZXh0LCB3 b3VsZCBpY2UgdHJpY2tsZSBhbmQgaWNlLXRyaWNrbGUtc2lwLVNEUCBmb2N1c3Npbmcgb24gdHJp Y2tsZSBpY2Ugb25seSBwcm9jZWR1cmVzIGFuZCB1c2FnZXMgbWFrZXMgc2Vuc2UgPw0KDQoNCkRv ZXMgdGhhdCB3b3JrID8NCg0KDQpPbiBUdWUsIEFwciAzLCAyMDE4IGF0IDExOjA0IEFNIEFkYW0g Um9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+PiB3cm90ZToN Ck9uIDQvMy8xOCAxMjo1NCBQTSwgQmVuIENhbXBiZWxsIHdyb3RlOg0KPg0KPj4gT24gQXByIDMs IDIwMTgsIGF0IDEyOjQzIFBNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVr ckBydGZtLmNvbT4+IHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4gT24gVHVlLCBBcHIgMywgMjAxOCBh dCAxMDozNSBBTSwgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0 cnVtLmNvbT4+IHdyb3RlOg0KPj4NCj4+DQo+Pj4gT24gQXByIDMsIDIwMTgsIGF0IDEyOjI2IFBN LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3Rl Og0KPj4+DQo+Pj4gSSBkb24ndCB0aGluayAjMyBpcyBhY2NlcHRhYmxlLiBBRkFJSyBKU0VQIGhh cyBubyBvdGhlciBkZXBlbmRlbmNpZXMgb24gU0lQLiBJZiB5b3UgdGhpbmsgIzIgYW5kICMzIGFy ZSBlcXVhbGx5IGF3a3dhcmQsIGxldHMgZG8gIzIuDQo+Pj4NCj4+IEkgc2FpZCB0aGV5IGFyZSBl cXVhbGx5IGF3a3dhcmQgKGJ5IHdoaWNoIEkgbWVhbiBlcXVhbGx5IGF3a3dhcmQgZm9yIHJlYWRl cnMgYWZ0ZXIgcHVibGljYXRpb24pLCBidXQgMyByZXF1aXJlcyBmZXdlciBjaGFuZ2VzICh0aGF0 IGlzLCBsZXNzIGVmZm9ydC4pLg0KPj4NCj4+IElmIHdlIHdhbnQgdG8gZ28gZm9yIGxlYXN0IGF3 a3dhcmQsIHRoYXQgcHJvYmFibHkgbWVhbnMgYSBzZXBhcmF0ZSB0cmlja2xlLWljZS1zZHAgZHJh ZnQgaW4gcGFyYWxsZWwgdG8gdGhlIGljZSBzZHAgZHJhZnQuIEJ1dCB0aGF04oCZcyB0aGUgcGFz dCBvZiBtb3N0IGVmZm9ydC4NCj4+DQo+PiBCdXQgaG9uZXN0bHksIEkgdGhpbmsgdGhpcyBpcyB0 aGUgc29ydCBvZiBwb2ludCB0aGF0IHdlIHNob3VsZCBkZWZlciB0byBXRyBjb25zZW5zdXMuDQo+ Pg0KPj4gV2hpY2ggV0c/IEFzIEkgdW5kZXJzdGFuZCBpdCwgdGhpcyB3b3VsZCByZXF1aXJlIGEg Y2hhbmdlIHRvIEpTRVAsIHdoaWNoIHdvdWxkIGFsc28gcmVxdWlyZSBXRyBjb25zZW5zdXMsIHBs dXMgYSBjaGFuZ2UgdG8gYW4gSUVTRy1hcHByb3ZlZCBkb2N1bWVudC4NCj4NCj4gSSBtZWFuIGNv bnNlbnN1cyBvZiB0aGUgV0dzIHByb2R1Y2luZyB0aGUgZG9jdW1lbnRzLiBpdOKAmXMgcXVpdGUg cmVhc29uYWJsZSBmb3IgYSBkZXBlbmRlbnQgV0cgdG8gb2ZmZXIgZmVlZGJhY2ssIGJ1dCBJIGRv buKAmXQgdGhpbmsgYSBkZXBlbmRlbnQgV0cgZ2V0cyB0byBqdXN0IG92ZXJyaWRlIHRoYXQgY29u c2Vuc3VzLg0KDQpJIGRvbid0IHRoaW5rIGl0J3MgYXMgY2xlYW4gY3V0IGFzIHRoYXQuIEpTRVAg Y291bGQgaGF2ZSBkZWZpbmVkIHRoZQ0KImE9ZW5kLW9mLWNhbmRpZGF0ZXMiIHN5bnRheCwgYW5k IGNlcnRhaW5seSB3b3VsZCBoYXZlIGlmIE1NVVNJQyBhbmQgSUNFDQpoYWQgcHVsbGVkIGl0IG91 dCBvZiB0aGVpciBkb2N1bWVudHMuIEJ1dCBJIGRvbid0IHRoaW5rIHdlIHdhbnQgYm90aA0KZG9j dW1lbnRzIGluZGVwZW5kZW50bHkgcmVnaXN0ZXJpbmcgaWRlbnRpY2FsIHN5bnRheGVzIHdpdGgg aWRlbnRpY2FsDQptZWFuaW5ncywgcmlnaHQ/IE9yIEkgc3VwcG9zZSBKU0VQIGNvdWxkIGhhdmUg ZGVjaWRlZCAtLSBoYXZpbmcgZmluaXNoZWQNCmZpcnN0IC0tIHRoYXQgdGhleSBzaG91bGQgZGVm aW5lIHRoZSBzeW50YXggYW5kIGhhdmUgdGhlIHRyaWNrbGUtaWNlLXNpcA0KZG9jdW1lbnQgcmVm ZXJlbmNlIEpTRVA/DQoNCkknbSBvZmZlcmluZyB0aG9zZSB1cCBhcyBleGFtcGxlcywgbm90IHBy b3Bvc2Fscy4gSSB0aGluayB0aGUgZmlyc3QgaXMgYQ0Kbm9uc3RhcnRlciwgYW5kIHRoZSBzZWNv bmQgaXMuLi4gd2VsbCwgaXQncyBhcyBhd2t3YXJkIGFzIHdoYXQgeW91J3JlDQpwcm9wb3Npbmcu DQoNCkknbSBiZWdpbm5pbmcgdG8gdGhpbmsgd2UgbmVlZCB0byB0byB0YWtlIHRoZSBxdWVzdGlv biB0byBBUlQgcmF0aGVyDQp0aGFuIHRoZSB0aHJlZSB3b3JraW5nIGdyb3Vwcy4NCg0KL2ENCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B72E43E90ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+Jmd0Ozwvc3Bhbj5MaWtlIEkgc2FpZCBvcmlnaW5hbGx5LCBub25lIG9mIHRoZXNlIGFyZSBw YXJ0aWN1bGFybHkgY2xlYW4uIFlvdXIgcHJvcG9zYWwgcG9pbnRzIHRvd2FyZHMgZWl0aGVyICMx IG9yICMzLCBhbmQNCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+Jmd0Ozwvc3Bhbj5JIGhpZ2hsaWdodGVkIHRoZWlyIGRyYXdiYWNrcyBpbiBteSBv cmlnaW5hbCBtZXNzYWdlLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7 PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7PC9zcGFuPkZ1 bmRhbWVudGFsbHksIHRoZSBzdWdnZXN0aW9uIEJlbiBtYWRlIGlzIHRoZSBvbmx5IGNsZWFuIG9u ZTogc3BsaXQgdHJpY2tsZS1pY2Utc2lwIGludG8gdHdvIGRvY3VtZW50czogb25lIGRlYWxzIHdp dGggU0lQICh0aGluayBhIHBhcmFsbGVsIHRvIFJGQyAzMjYxKQ0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPiZndDs8L3NwYW4+d2hpbGUgdGhlIG90aGVyIGRlYWxzIHdpdGggU0RQICh0 aGluayBhIHBhcmFsbGVsIHRvIFJGQyAzMjY0KS4gQnV0IEkgYWxzbyBhZ3JlZSB3aXRoIGhpbSB0 aGF0IHNlbmRpbmcgdGhlIGRvY3VtZW50IGJhY2sgdG8gdGhlIFdHIGZvciBzdWNoIGEgc3BsaXQg d291bGQNCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7PC9zcGFuPmludHJvZHVj ZSBhIHNpZ25pZmljYW50IGFtb3VudCBvZiB3b3JrLjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Tm90IGV4YWN0bHkgc3VyZSB3 aGF0IOKAnGRlYWxzIHdpdGggU0RQ4oCdIHdvdWxkIG1lYW4sIGJ1dCBvbmUgaWRlYSB3b3VsZCBi ZSB0byBPTkxZIGRlZmluZSB0aGUgYXR0cmlidXRlLCBhbmQgdGhlIGFzc29jaWF0ZWQgTy9BIHBy b2NlZHVyZXMsIGluIGEgc2VwYXJhdGUgZHJhZnQsDQogdGhhdCB3b3VsZCBiZSByZWZlcmVuY2Vk IGJ5IGRyYWZ0LWlldGYtbW11c2ljLXRyaWNrbGUtaWNlLXNpcCBhbmQgSlNFUC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5DaHJpc3RlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNC8zLzE4IDE6MjEgUE0sIFN1 aGFzIE5hbmRha3VtYXIgd3JvdGU6PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFkZGluZyBhIGRhdGEgcG9pbnQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWNlYmlzIGRvZXNu4oCZdCB0YWxrIGFi b3V0IHRyaWNrbGUgaWNlIGFuZCBoZW5jZSBpY2Utc2lwLVNEUCBkb2VzbuKAmXQgZWl0aGVyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0 aGUgc2FtZSBjb250ZXh0LCB3b3VsZCBpY2UgdHJpY2tsZSBhbmQgaWNlLXRyaWNrbGUtc2lwLVNE UCBmb2N1c3Npbmcgb24gdHJpY2tsZSBpY2Ugb25seSBwcm9jZWR1cmVzIGFuZCB1c2FnZXMgbWFr ZXMgc2Vuc2UgPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRvZXMgdGhhdCB3b3JrID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBcHIgMywgMjAxOCBhdCAxMTowNCBBTSBB ZGFtIFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+YWRhbUBub3N0 cnVtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNC8zLzE4IDEyOjU0IFBNLCBCZW4gQ2FtcGJlbGwg d3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IE9uIEFwciAzLCAyMDE4LCBhdCAxMjo0MyBQ TSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIFR1ZSwgQXByIDMsIDIwMTgg YXQgMTA6MzUgQU0sIEJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBub3N0cnVt LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlbkBub3N0cnVtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gQXByIDMsIDIwMTgs IGF0IDEyOjI2IFBNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0u Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgZG9uJ3QgdGhpbmsgIzMgaXMgYWNjZXB0YWJs ZS4gQUZBSUsgSlNFUCBoYXMgbm8gb3RoZXIgZGVwZW5kZW5jaWVzIG9uIFNJUC4gSWYgeW91IHRo aW5rICMyIGFuZCAjMyBhcmUgZXF1YWxseSBhd2t3YXJkLCBsZXRzIGRvICMyLjxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgc2FpZCB0aGV5IGFyZSBlcXVhbGx5IGF3a3dhcmQgKGJ5 IHdoaWNoIEkgbWVhbiBlcXVhbGx5IGF3a3dhcmQgZm9yIHJlYWRlcnMgYWZ0ZXIgcHVibGljYXRp b24pLCBidXQgMyByZXF1aXJlcyBmZXdlciBjaGFuZ2VzICh0aGF0IGlzLCBsZXNzIGVmZm9ydC4p Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSWYgd2Ugd2FudCB0byBnbyBmb3IgbGVhc3Qg YXdrd2FyZCwgdGhhdCBwcm9iYWJseSBtZWFucyBhIHNlcGFyYXRlIHRyaWNrbGUtaWNlLXNkcCBk cmFmdCBpbiBwYXJhbGxlbCB0byB0aGUgaWNlIHNkcCBkcmFmdC4gQnV0IHRoYXTigJlzIHRoZSBw YXN0IG9mIG1vc3QgZWZmb3J0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQnV0IGhvbmVz dGx5LCBJIHRoaW5rIHRoaXMgaXMgdGhlIHNvcnQgb2YgcG9pbnQgdGhhdCB3ZSBzaG91bGQgZGVm ZXIgdG8gV0cgY29uc2Vuc3VzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2hpY2ggV0c/ IEFzIEkgdW5kZXJzdGFuZCBpdCwgdGhpcyB3b3VsZCByZXF1aXJlIGEgY2hhbmdlIHRvIEpTRVAs IHdoaWNoIHdvdWxkIGFsc28gcmVxdWlyZSBXRyBjb25zZW5zdXMsIHBsdXMgYSBjaGFuZ2UgdG8g YW4gSUVTRy1hcHByb3ZlZCBkb2N1bWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIG1lYW4gY29u c2Vuc3VzIG9mIHRoZSBXR3MgcHJvZHVjaW5nIHRoZSBkb2N1bWVudHMuIGl04oCZcyBxdWl0ZSBy ZWFzb25hYmxlIGZvciBhIGRlcGVuZGVudCBXRyB0byBvZmZlciBmZWVkYmFjaywgYnV0IEkgZG9u 4oCZdCB0aGluayBhIGRlcGVuZGVudCBXRyBnZXRzIHRvIGp1c3Qgb3ZlcnJpZGUgdGhhdCBjb25z ZW5zdXMuPGJyPg0KPGJyPg0KSSBkb24ndCB0aGluayBpdCdzIGFzIGNsZWFuIGN1dCBhcyB0aGF0 LiBKU0VQIGNvdWxkIGhhdmUgZGVmaW5lZCB0aGU8YnI+DQomcXVvdDthPWVuZC1vZi1jYW5kaWRh dGVzJnF1b3Q7IHN5bnRheCwgYW5kIGNlcnRhaW5seSB3b3VsZCBoYXZlIGlmIE1NVVNJQyBhbmQg SUNFPGJyPg0KaGFkIHB1bGxlZCBpdCBvdXQgb2YgdGhlaXIgZG9jdW1lbnRzLiBCdXQgSSBkb24n dCB0aGluayB3ZSB3YW50IGJvdGg8YnI+DQpkb2N1bWVudHMgaW5kZXBlbmRlbnRseSByZWdpc3Rl cmluZyBpZGVudGljYWwgc3ludGF4ZXMgd2l0aCBpZGVudGljYWw8YnI+DQptZWFuaW5ncywgcmln aHQ/IE9yIEkgc3VwcG9zZSBKU0VQIGNvdWxkIGhhdmUgZGVjaWRlZCAtLSBoYXZpbmcgZmluaXNo ZWQ8YnI+DQpmaXJzdCAtLSB0aGF0IHRoZXkgc2hvdWxkIGRlZmluZSB0aGUgc3ludGF4IGFuZCBo YXZlIHRoZSB0cmlja2xlLWljZS1zaXA8YnI+DQpkb2N1bWVudCByZWZlcmVuY2UgSlNFUD88YnI+ DQo8YnI+DQpJJ20gb2ZmZXJpbmcgdGhvc2UgdXAgYXMgZXhhbXBsZXMsIG5vdCBwcm9wb3NhbHMu IEkgdGhpbmsgdGhlIGZpcnN0IGlzIGE8YnI+DQpub25zdGFydGVyLCBhbmQgdGhlIHNlY29uZCBp cy4uLiB3ZWxsLCBpdCdzIGFzIGF3a3dhcmQgYXMgd2hhdCB5b3UncmU8YnI+DQpwcm9wb3Npbmcu PGJyPg0KPGJyPg0KSSdtIGJlZ2lubmluZyB0byB0aGluayB3ZSBuZWVkIHRvIHRvIHRha2UgdGhl IHF1ZXN0aW9uIHRvIEFSVCByYXRoZXI8YnI+DQp0aGFuIHRoZSB0aHJlZSB3b3JraW5nIGdyb3Vw cy48YnI+DQo8YnI+DQovYTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B72E43E90ESESSMB109erics_-- From nobody Tue Apr 3 13:42:11 2018 Return-Path: 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 A3F0B12D868 for ; Tue, 3 Apr 2018 12:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 Wz4d3zd1OSht for ; Tue, 3 Apr 2018 12:20:10 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A571912D86B for ; Tue, 3 Apr 2018 12:20:10 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id v194-v6so24292675itb.0 for ; Tue, 03 Apr 2018 12:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bzH2tNo5SSXPsue2nlimcG4u0gM3hKtBF3RlXVqb8i4=; b=Li4EwRk5wEypliSg11A0RLyQQOk+3oJOHZWTYmmi3QKww7mJ03WcWfViJQM7JsTj/h 1/DiT5WT+kdHwqP8BfyN/QrAufxSerfhfpgDWKn39OUgdtjSz6LwlvpwMIKauYETCc75 K0XjGv2DpYXIwYHUZvZdwUTuqvOL8DuSraMjE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=bzH2tNo5SSXPsue2nlimcG4u0gM3hKtBF3RlXVqb8i4=; b=lQ6nbyd1T+YxkN3wx+30OphnwPXPUy4ro8WtBNhHrkxaQDYVk7XC1iECfSzqi6SJnA Pvylm7RRBOFqkbaZVPG8jqB3/A+LDgoU2xXFpZU2Jy81t+bWff9AhsioS5SIj3alNeG2 JeXCk0Y3DQkqmbZgmr57Gly+BbeHC0iLlJpZS6xz+BBu3umePZGuCozEuq6gRolwsf1+ 7fHZ0+FmZHrNAmcVsLsrQyWWj2Gtqf7P3Zgunnr1DyI28balEZkwrC2pqNAPe8CtsDEI 6ZistsQY4Qm3GLw8tUAxhSCKZGAwz4+k9RRArj3jpJaZY9mrVfZwQSbiO340jT+g5n12 3Rjw== X-Gm-Message-State: ALQs6tA0tq33xi1J+nYOP5JeXPpsTc+s6Kuv2aJfcy3oJ6hn+Y+wKKeu /se3R3NQ6icg5RHspRGwqP59qQ== X-Google-Smtp-Source: AIpwx48JdPBtTwV/N7XlQfI7cq7AiaqjHJ3X+nrlXZOj9xEU4JVz+78UDc3E6xMtGFMQxKMoBk5kVQ== X-Received: by 2002:a24:c902:: with SMTP id h2-v6mr6051865itg.61.1522783210030; Tue, 03 Apr 2018 12:20:10 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id 194-v6sm862143itm.15.2018.04.03.12.20.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 12:20:09 -0700 (PDT) To: Suhas Nandakumar , Adam Roach Cc: Ben Campbell , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> Date: Tue, 3 Apr 2018 13:20:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 13:41:48 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 19:20:13 -0000 On 4/3/18 12:27 PM, Suhas Nandakumar wrote: > Just to complete, ice-bis doesn’t normatively reference ice-sip-SDP > draft when it moved to using “usages “ indirections for signaling protocols. > > > Trickle ice can use similar approach and refer to trickle-sip as usage > for trickle. It already does. That's why we pulled all the SDP/SIP stuff out of draft-ietf-ice-trickle. Peter From nobody Tue Apr 3 13:42:15 2018 Return-Path: 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 24D2612D868; Tue, 3 Apr 2018 12:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 q5LrD4cLvM7m; Tue, 3 Apr 2018 12:22:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B671242F7; Tue, 3 Apr 2018 12:22:13 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w33JM7P6006475 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Apr 2018 14:22:08 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F245D20C-39E2-4BD0-9212-91B2FF7723BE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 3 Apr 2018 14:22:07 -0500 In-Reply-To: <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> Cc: Suhas Nandakumar , Adam Roach , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org To: Peter Saint-Andre References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 13:41:48 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 19:22:15 -0000 --Apple-Mail=_F245D20C-39E2-4BD0-9212-91B2FF7723BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre = wrote: >=20 > On 4/3/18 12:27 PM, Suhas Nandakumar wrote: >> Just to complete, ice-bis doesn=E2=80=99t normatively reference = ice-sip-SDP >> draft when it moved to using =E2=80=9Cusages =E2=80=9C indirections = for signaling protocols. >>=20 >>=20 >> Trickle ice can use similar approach and refer to trickle-sip as = usage >> for trickle. >=20 > It already does. That's why we pulled all the SDP/SIP stuff out of > draft-ietf-ice-trickle. I assume Suhas meant separating the SDP stuff from the SIP stuff. (I = also assume he will correct me if I am wrong.) Thanks, Ben. --Apple-Mail=_F245D20C-39E2-4BD0-9212-91B2FF7723BE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrD1F8ACgkQgFZKbJXz 1A2Iqw//WgI389gyLqsJz5beKg5/rdC5MHTRXbQg0qxCGI32jhmKqmootFjmT4lK Dx3BZB5yJBT/Ny7v3aXcbD7pz8UWFFXKYtn0svO0M4tk8VBRW6ti8H6zq1it6H+8 6nAvaSVj5e1+H++4CrrBmzxrnxmjSFSIDFtBqiByickXiaKzTDRtJCWriwhCQRgf Q4xWXo81WmD6RTuPlvusr3PtQykzhxsQSe+buprrGvrAL+eQuic96ZKvwTsWS2HY gimFCENGifQ3oW8UrUtJcwnBVAN70PMjmZxqL4FfTolTTNjTpFxvCsktoNr18985 QsPynmxWOEgQjcryZZht6KU0S9UNeIf957S6/n+JVOizSgvx7xCMU4R9m8B2YT4o JxMlWy7x1PL7gHNou0UAEhug8XM0fnR+Bp6XyLfhh4CYTTMpnEV71Q9O0CbDhwlV qumq7VVLUr95x+Vd6OnIqZY2QyUROsV0T+fZMm1uawgLbBKARPvBbCoE2v8FbdM5 ut0PvFbg6Jvj951NrIl4acLkbn7EAYGYsECcGKR6s2xUpNXOUEvCDl6u77vXjk2w ETDP+NLlJdbgsxP2pFMDgG/5/I3ayUYKo6VQkzTwGTWLz/dCU98nG9AH96hWsATh q2DhRin1i9TeiF6KbgDcvLrB/JEHsVojnQx6n6eXGpyWn7mOp+I= =D3vU -----END PGP SIGNATURE----- --Apple-Mail=_F245D20C-39E2-4BD0-9212-91B2FF7723BE-- From nobody Tue Apr 3 13:42:19 2018 Return-Path: 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 52E3112EA64; Tue, 3 Apr 2018 12:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 rgZIR5PTDs_M; Tue, 3 Apr 2018 12:34:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834B312D864; Tue, 3 Apr 2018 12:34:25 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w33JYLsL008394 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Apr 2018 14:34:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <9AE05B60-9E8E-42C8-B114-3A92A0186604@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_ED5E25F7-8FAC-49FF-92D7-180512CF7808"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 3 Apr 2018 14:34:20 -0500 In-Reply-To: <0503b397-787a-a0de-15aa-dc6dee57a4f8@nostrum.com> Cc: Suhas Nandakumar , Eric Rescorla , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org To: Adam Roach , Roman Shpount , Peter Saint-Andre References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <0503b397-787a-a0de-15aa-dc6dee57a4f8@nostrum.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 13:41:48 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 19:34:29 -0000 --Apple-Mail=_ED5E25F7-8FAC-49FF-92D7-180512CF7808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 3, 2018, at 1:28 PM, Adam Roach wrote: >=20 > Like I said originally, none of these are particularly clean. Your = proposal points towards either #1 or #3, and I highlighted their = drawbacks in my original message. >=20 > Fundamentally, the suggestion Ben made is the only clean one: split = trickle-ice-sip into two documents: one deals with SIP (think a parallel = to RFC 3261) while the other deals with SDP (think a parallel to RFC = 3264). But I also agree with him that sending the document back to the = WG for such a split would introduce a significant amount of work. >=20 > Absent that, we need to pick which wart we're going to accept. Roman suggested in s separate thread branch that there is more to this = than just "a=3Dend-of-candidates=E2=80=9D. Roman said: > It is not just end-of-candidates, but also support for c=3D0.0.0.0 in = offers, SDP offers without the candidates, different mismatch rules. As = it stands, draft-ietf-mmusic-trickle-ice-sip changes how = draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used. >=20 =E2=80=A6 and also =E2=80=A6 > For instance current in draft-ietf-rtcweb-jsep-24 = (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-5.2.1): >=20 > If the m=3D section is marked as bundle-only, then the port value MUST = be set to 0. Otherwise, the port value is set to the port of the = default ICE candidate for this m=3D section, but given that no = candidates are available yet, the "dummy" port value of 9 (Discard) MUST = be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1. >=20 > I am fairly sure this is no longer in ietf-ice-trickle and was moved = to draft-ietf-mmusic-trickle-ice-sip = (https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-14#section-= 4.1.1). I think maybe we need a sweep of jsep to get a definitive list of = references that need to change due the current document structure. = Without that list, it=E2=80=99s hard to really assess the amount of work = implied by each proposed fix. (Note that we will need such a list one = way or another before JSEP can be published=E2=80=94so this does not add = new work per se.) Roman and Peter: Can you compile a list? Perhaps with the assistance of = a JSEP author? (I=E2=80=99d suggest Ekr, but I know that as an AD his = time is scarce this week.) Thanks! Ben. >=20 > /a >=20 > On 4/3/18 1:21 PM, Suhas Nandakumar wrote: >> Adding a data point >>=20 >> Icebis doesn=E2=80=99t talk about trickle ice and hence ice-sip-SDP = doesn=E2=80=99t either. >>=20 >> In the same context, would ice trickle and ice-trickle-sip-SDP = focussing on trickle ice only procedures and usages makes sense ? >>=20 >>=20 >> Does that work ? >>=20 >>=20 >> On Tue, Apr 3, 2018 at 11:04 AM Adam Roach wrote: >> On 4/3/18 12:54 PM, Ben Campbell wrote: >> > >> >> On Apr 3, 2018, at 12:43 PM, Eric Rescorla wrote: >> >> >> >> >> >> >> >> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell = wrote: >> >> >> >> >> >>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla wrote: >> >>> >> >>> I don't think #3 is acceptable. AFAIK JSEP has no other = dependencies on SIP. If you think #2 and #3 are equally awkward, lets do = #2. >> >>> >> >> I said they are equally awkward (by which I mean equally awkward = for readers after publication), but 3 requires fewer changes (that is, = less effort.). >> >> >> >> If we want to go for least awkward, that probably means a separate = trickle-ice-sdp draft in parallel to the ice sdp draft. But that=E2=80=99s= the past of most effort. >> >> >> >> But honestly, I think this is the sort of point that we should = defer to WG consensus. >> >> >> >> Which WG? As I understand it, this would require a change to JSEP, = which would also require WG consensus, plus a change to an IESG-approved = document. >> > >> > I mean consensus of the WGs producing the documents. it=E2=80=99s = quite reasonable for a dependent WG to offer feedback, but I don=E2=80=99t= think a dependent WG gets to just override that consensus. >>=20 >> I don't think it's as clean cut as that. JSEP could have defined the >> "a=3Dend-of-candidates" syntax, and certainly would have if MMUSIC = and ICE >> had pulled it out of their documents. But I don't think we want both >> documents independently registering identical syntaxes with identical >> meanings, right? Or I suppose JSEP could have decided -- having = finished >> first -- that they should define the syntax and have the = trickle-ice-sip >> document reference JSEP? >>=20 >> I'm offering those up as examples, not proposals. I think the first = is a >> nonstarter, and the second is... well, it's as awkward as what you're >> proposing. >>=20 >> I'm beginning to think we need to to take the question to ART rather >> than the three working groups. >>=20 >> /a >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 --Apple-Mail=_ED5E25F7-8FAC-49FF-92D7-180512CF7808 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrD1zwACgkQgFZKbJXz 1A0K9w//R89RIGaomYmvm/2UeSPSunfm3nMeOkEDmqGFgMlZrIg2orHim+DOvWXF a4skwAnf18KnC0GncSup5V6T7DFUBtWL73mgBpuwhJugCCLdZFekL9mNeuyVbWAt MyZDROE11Q+WI4XneCX6Fguv0DSxVglsMtvyfSYYvsYH7fAqVngYjhDnzA5uf2BW EItlXajYqTERZyzZD9bjsakJUuB0kbf3Kah+WS0ENtsrCgLESJ9124+r9E7B6jiW 1byMSuDDIY1O0oVDpZImGuIos6h+xVmIxuMd1ZkWxM6JpmR9xTECMb8kmx+eQoaP XVIHpOa4BIhU+EkZEEwsHP0Lur5eP+3aknh8Bg3fdOACqb/IQrnqRkSpz/VGb9j0 cA5eQnjmY6h9L6Z3dknb/Q0SnJQ2SpUV3WHjbSn3zjeoSBBDlwrprHn1qRofw1Wh cl8kab4UNnmfX67lb+i+fy2TQw3flA8U2PtSdqmlU/+aGbbMQFQBWLv7WhCyx+6g AZ2XKBMcc0KzG89WB4UdNlGyloGpd/qSSfCMXoHhTPPAJSeotDmJlsJ5BlBjgVKg 8GJ86UIftcd0/MAow+n4MAxoin4iB1h93XqxKY983DidjoCGvyhQ6sR6r1hNJFNo qOJnhMS45neWvtG7Z4h3oUmlfcC1zdQhOKd9yYtSW+kxHDhfK+8= =++aR -----END PGP SIGNATURE----- --Apple-Mail=_ED5E25F7-8FAC-49FF-92D7-180512CF7808-- From nobody Tue Apr 3 13:42:28 2018 Return-Path: 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 13BA412D86C for ; Tue, 3 Apr 2018 13:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 ZhDrOb1HQ0EC for ; Tue, 3 Apr 2018 13:12:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 4C2AB1267BB for ; Tue, 3 Apr 2018 13:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522786348; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=baPLodCsgz6QszvzwuHZczTKUetnJbc3AxyHV8MXy0M=; b=fP9Y8ipinDs8xzDFQ2Wpnbl/WebmQ0UD65w0eDbikEd0in5UFMA/lb60jfJDnggg Ce/lraPXZ9cgvGq/affFnfZ4QP8KNTmUf5gssQ+H2uPniWq5BjsmAZxoB2G+TZWF xmiWdX3twNJ/x9dz2RAzARTPy5Sx0JoIBi2LJtLLU9I=; X-AuditID: c1b4fb2d-e19ff700000073d9-62-5ac3e02c68c6 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.6D.29657.C20E3CA5; Tue, 3 Apr 2018 22:12:28 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0382.000; Tue, 3 Apr 2018 22:12:27 +0200 From: Christer Holmberg To: Ben Campbell , Adam Roach , "Roman Shpount" , Peter Saint-Andre CC: Suhas Nandakumar , Eric Rescorla , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAAB8QCAABJGAIAAJ6xw Date: Tue, 3 Apr 2018 20:12:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E4424B@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <0503b397-787a-a0de-15aa-dc6dee57a4f8@nostrum.com> <9AE05B60-9E8E-42C8-B114-3A92A0186604@nostrum.com> In-Reply-To: <9AE05B60-9E8E-42C8-B114-3A92A0186604@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUyM2K7uq7Og8NRBvtey1rs+buI3WJ+52l2 ix9rlzNbrHh9jt3i/QVdi28Xai1m/JnIbHF+53omi6nLH7NYzLgwldli7b92dotnK08xWuyc 28HswOsx5fdGVo+ds+6yeyxZ8pPJo+9AF6vHrJ1PWDwmP25j9rg1pSCAPYrLJiU1J7MstUjf LoEr48GMt6wF+xQrrs5ew9LAeEGhi5GTQ0LAROLjuZlsXYxcHEICRxglrly7yg7hLGaUeLJr DmsXIwcHm4CFRPc/bZC4iMBERolPM4+AFTELtDBL3Pv+kR1klLBAgcTGOa1sILaIQKHE2h2P 2ECaRQTyJA4eFAYJswioSKz7vp4JxOYV8JX4tn8NE8SyU6wSv5c2gM3hFLCXuDrxBguIzSgg JvH91BqwBmYBcYlbT+YzQZwtILFkz3lmCFtU4uXjf6wQtpLE0/9LmED2MgtoSqzfpQ/Rqigx pfshO8ReQYmTM5+wTGAUnYVk6iyEjllIOmYh6VjAyLKKUbQ4tbg4N93IWC+1KDO5uDg/Ty8v tWQTIzCCD275rbuDcfVrx0OMAhyMSjy8p+8ejhJiTSwrrsw9xCjBwawkwquwGSjEm5JYWZVa lB9fVJqTWnyIUZqDRUmcV2/VnighgfTEktTs1NSC1CKYLBMHp1QDo1rDQ4NNhTcMnoSU+T4U LJDbXsJt4rHoVNxGjunXz21vrvM5lBo65bK88tR/RtvWFGa0FF1b8J2n+tfzukd5BfZCHB5X Zu5pDIm74mhRzjpf4yrHolv/VnmLX//sycF3uMde7u7aeMcWefYLipNcJzMzchxnc9vt53mg 0CBpitzkv3aOPheuKLEUZyQaajEXFScCAJNWe9bcAgAA Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 13:41:48 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:12:33 -0000 SGksDQoNCj4+IExpa2UgSSBzYWlkIG9yaWdpbmFsbHksIG5vbmUgb2YgdGhlc2UgYXJlIHBhcnRp Y3VsYXJseSBjbGVhbi4gWW91ciBwcm9wb3NhbCBwb2ludHMgdG93YXJkcyBlaXRoZXIgIzEgb3Ig IzMsIGFuZCBJIGhpZ2hsaWdodGVkIHRoZWlyIGRyYXdiYWNrcyBpbiBteSBvcmlnaW5hbCBtZXNz YWdlLg0KPj4gDQo+PiBGdW5kYW1lbnRhbGx5LCB0aGUgc3VnZ2VzdGlvbiBCZW4gbWFkZSBpcyB0 aGUgb25seSBjbGVhbiBvbmU6IHNwbGl0IHRyaWNrbGUtaWNlLXNpcCBpbnRvIHR3byBkb2N1bWVu dHM6IG9uZSBkZWFscyB3aXRoIA0KPj4gU0lQICh0aGluayBhIHBhcmFsbGVsIHRvIFJGQyAzMjYx KSB3aGlsZSB0aGUgb3RoZXIgZGVhbHMgd2l0aCBTRFAgKHRoaW5rIGEgcGFyYWxsZWwgdG8gUkZD IDMyNjQpLiBCdXQgSSBhbHNvIGFncmVlIHdpdGggaGltIA0KPj4gdGhhdCBzZW5kaW5nIHRoZSBk b2N1bWVudCBiYWNrIHRvIHRoZSBXRyBmb3Igc3VjaCBhIHNwbGl0IHdvdWxkIGludHJvZHVjZSBh IHNpZ25pZmljYW50IGFtb3VudCBvZiB3b3JrLg0KPj4gDQo+PiBBYnNlbnQgdGhhdCwgd2UgbmVl ZCB0byBwaWNrIHdoaWNoIHdhcnQgd2UncmUgZ29pbmcgdG8gYWNjZXB0Lg0KPg0KPiBSb21hbiBz dWdnZXN0ZWQgaW4gYSBzZXBhcmF0ZSB0aHJlYWQgYnJhbmNoIHRoYXQgdGhlcmUgaXMgbW9yZSB0 byB0aGlzIHRoYW4ganVzdCAiYT1lbmQtb2YtY2FuZGlkYXRlc+KAnS4gUm9tYW4gc2FpZDoNCj4N Cj4gSXQgaXMgbm90IGp1c3QgZW5kLW9mLWNhbmRpZGF0ZXMsIGJ1dCBhbHNvIHN1cHBvcnQgZm9y IGM9MC4wLjAuMCBpbiBvZmZlcnMsIFNEUCBvZmZlcnMgd2l0aG91dCB0aGUgY2FuZGlkYXRlcywg ZGlmZmVyZW50IG1pc21hdGNoIA0KPiBydWxlcy4gQXMgaXQgc3RhbmRzLCBkcmFmdC1pZXRmLW1t dXNpYy10cmlja2xlLWljZS1zaXAgY2hhbmdlcyBob3cgZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNp cC1zZHAgd29ya3Mgd2hlbiB0cmlja2xlIElDRSBpcyB1c2VkLg0KPg0KPuKApiBhbmQgYWxzbyDi gKYNCj4NCj4gRm9yIGluc3RhbmNlIGN1cnJlbnQgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItanNlcC0y NCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWpzZXAtMjQj c2VjdGlvbi01LjIuMSk6DQo+IA0KPiBJZiB0aGUgbT0gc2VjdGlvbiBpcyBtYXJrZWQgYXMgYnVu ZGxlLW9ubHksIHRoZW4gdGhlIHBvcnQgdmFsdWUgTVVTVCBiZSBzZXQgdG8gMC4gIE90aGVyd2lz ZSwgdGhlIHBvcnQgdmFsdWUgaXMgc2V0IHRvIHRoZSBwb3J0IA0KPiBvZiB0aGUgZGVmYXVsdCBJ Q0UgY2FuZGlkYXRlIGZvciB0aGlzIG09IHNlY3Rpb24sIGJ1dCBnaXZlbiB0aGF0IG5vIGNhbmRp ZGF0ZXMgYXJlIGF2YWlsYWJsZSB5ZXQsIHRoZSAiZHVtbXkiIHBvcnQgdmFsdWUgb2YgDQo+IDkg KERpc2NhcmQpIE1VU1QgYmUgdXNlZCwgYXMgaW5kaWNhdGVkIGluIFtJLUQuaWV0Zi1pY2UtdHJp Y2tsZV0sIFNlY3Rpb24gNS4xLg0KPiANCj4gSSBhbSBmYWlybHkgc3VyZSB0aGlzIGlzIG5vIGxv bmdlciBpbiBpZXRmLWljZS10cmlja2xlICBhbmQgd2FzIG1vdmVkIHRvIGRyYWZ0LWlldGYtbW11 c2ljLXRyaWNrbGUtaWNlLXNpcCANCj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1tdXNpYy10cmlja2xlLWljZS1zaXAtMTQjc2VjdGlvbi00LjEuMSkuDQoNCkluIGFk ZGl0aW9uIHRvIHRoYXQsIGRyYWZ0LWlldGYtbW11c2ljLXRyaWNrbGUtaWNlLXNpcCBhbHNvIGRl ZmluZXMgdGhlIFNEUCB1c2FnZSBvZiAiYT1pY2Utb3B0aW9uczp0cmlja2xlIi4gSlNFUCBjdXJy ZW50bHkgcmVmZXJlbmNlcyBkcmFmdC1pZXRmLWljZS10cmlja2xlIHJlZ2FyZGluZyB1c2FnZSBv ZiB0aGUgYXR0cmlidXRlIChzZWUgYmVsb3cpLCBidXQgdGhlIG9ubHkgdGhpbmcgZHJhZnQtaWV0 Zi1pY2UtdHJpY2tsZSBkb2VzIGlzIHJlZ2lzdGVyaW5nIHRoZSAidHJpY2tsZSIgdG9rZW4uIA0K DQpFeGFtcGxlczoNCg0KU2VjdGlvbiA1LjIuMSBzYXlzOg0KDQoibyAgQW4gImE9aWNlLW9wdGlv bnMiIGxpbmUgd2l0aCB0aGUgInRyaWNrbGUiIG9wdGlvbiBNVVNUIGJlIGFkZGVkLA0KICAgICAg YXMgc3BlY2lmaWVkIGluIFtJLUQuaWV0Zi1pY2UtdHJpY2tsZV0sIFNlY3Rpb24gNC4iDQoNClRo ZXJlIGlzIG5vIHRleHQgYWJvdXQgdGhlICJ0cmlja2xlIiBvcHRpb24gaW4gU2VjdGlvbiA0IG9m IGRyYWZ0LWlldGYtaWNlLXRyaWNrbGUuDQoNCg0KU2VjdGlvbiA1LjIuMSBhbHNvIHNheXM6DQoN CiAgICAgICJJZiB0aGUgbT0gc2VjdGlvbiBpcyBtYXJrZWQgYXMgYnVuZGxlLW9ubHksIHRoZW4g dGhlIHBvcnQgdmFsdWUNCiAgICAgIE1VU1QgYmUgc2V0IHRvIDAuICBPdGhlcndpc2UsIHRoZSBw b3J0IHZhbHVlIGlzIHNldCB0byB0aGUgcG9ydCBvZg0KICAgICAgdGhlIGRlZmF1bHQgSUNFIGNh bmRpZGF0ZSBmb3IgdGhpcyBtPSBzZWN0aW9uLCBidXQgZ2l2ZW4gdGhhdCBubw0KICAgICAgY2Fu ZGlkYXRlcyBhcmUgYXZhaWxhYmxlIHlldCwgdGhlICJkdW1teSIgcG9ydCB2YWx1ZSBvZiA5DQog ICAgICAoRGlzY2FyZCkgTVVTVCBiZSB1c2VkLCBhcyBpbmRpY2F0ZWQgaW4gW0ktRC5pZXRmLWlj ZS10cmlja2xlXSwNCiAgICAgIFNlY3Rpb24gNS4xLiINCg0KLi4uYW5kOg0KDQogICAiVGhlIG09 IGxpbmUgTVVTVCBiZSBmb2xsb3dlZCBpbW1lZGlhdGVseSBieSBhICJjPSIgbGluZSwgYXMgc3Bl Y2lmaWVkDQogICBpbiBbUkZDNDU2Nl0sIFNlY3Rpb24gNS43LiAgQWdhaW4sIGFzIG5vIGNhbmRp ZGF0ZXMgYXJlIGF2YWlsYWJsZQ0KICAgeWV0LCB0aGUgImM9IiBsaW5lIG11c3QgY29udGFpbiB0 aGUgImR1bW15IiB2YWx1ZSAiSU4gSVA0IDAuMC4wLjAiLA0KICAgYXMgZGVmaW5lZCBpbiBbSS1E LmlldGYtaWNlLXRyaWNrbGVdLCBTZWN0aW9uIDUuMS4iDQoNClRoZXJlIGlzIG5vIHRleHQgYWJv dXQgZHVtbXkgdmFsdWVzIChwb3J0cyBvciBhZGRyZXNzZXMpIGV0YyBpbiBTZWN0aW9uIDUuMSBv ZiBkcmFmdC1pZXRmLWljZS10cmlja2xlLg0KDQpTaW1pbGFyIHRleHQgZXhpc3RzIGZvciB0aGUg YW5zd2VyIGluIHNlY3Rpb24gNS4zLjEuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Tue Apr 3 13:42:32 2018 Return-Path: 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 EC731128C0A; Tue, 3 Apr 2018 13:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 k50qt1Wna9Wo; Tue, 3 Apr 2018 13:41:31 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A66A12706D; Tue, 3 Apr 2018 13:41:30 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id d201so6676446vke.0; Tue, 03 Apr 2018 13:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jnqQ3AS0Vc0Jd/S6psKReE5OAtSHnvUtdevBMf83534=; b=QQDUUNFE0DV/Jo908Hbtye0VMz6SYPMwd++jj4mvIW69Ks55fqR8NPabM405oXgXpw e52ywdCPblWgdxC6HiGFF8UIcFKnsyYmcfywdN/rimHeF0tHGC5womK0D+khx1LknPTA xjNBZwfaMzDzc3qzH/HqSfvWK7mcXkesbLDILqhvtXkbU37XmNtavvOEEFa3AU43lZhk GfbmgUsvGarJORpgkl6tGqdY37OyJq0u7AYl8hL3OWMGKizQwSHEeUswdVNM6/6e3c4s LVEIgP8uKNSpiHSdSCN/vGa8V4daJRagyf3HxhGGm9kL+Vjw0b7VamLZkBxdwKGkAUDR QyZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jnqQ3AS0Vc0Jd/S6psKReE5OAtSHnvUtdevBMf83534=; b=D6fpxIntzIIUo4R+2nU66A3QUTAOUfcUvgWioGt1geN7y8wpMN8J7VMgtX3joycr1F yndzwI34lI32QQ0As69z6WBCe9+/23j5ISVetTjU38Na4n1FaeBKxJt0jdRuoyaailza oktfnOVnDf/NlAwGnqTgAIGTmzuNkXOt3sV3Q1CiwZdA0ijeEIOMElA2EAlKo8eHc5iQ 03GmiSWfdMmekIW7KvCYSh6LgmwPXgbVV4h+v/gFRojYuo9mVHKAEM/ZM49f67dmWkPx LcGvcLiWpkp9Dfl/EJTSfJpOB59WLm35mzviunKoFQc2qToHOvaTaLq96hh4/Z1b8346 6I+Q== X-Gm-Message-State: ALQs6tAVjZnx+ViLwx9yStCWzl/tm7eNsWIJ8Nm3Fo7FWLDaWdNjGP6W 35wUs6ku6TELn2FVhOInP7Xe8MkROX4tAG9DeJQ= X-Google-Smtp-Source: AIpwx49+MgG/kU1DwQwRSyHmvu1tHKid2ILoLswSOR+e3walVx0mskpirKxc4H5MiiniaFy3m5ZjqgV5iOrdgJz2Ly8= X-Received: by 10.31.140.196 with SMTP id o187mr5712588vkd.4.1522788089811; Tue, 03 Apr 2018 13:41:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.82 with HTTP; Tue, 3 Apr 2018 13:41:29 -0700 (PDT) In-Reply-To: <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> From: Suhas Nandakumar Date: Tue, 3 Apr 2018 13:41:29 -0700 Message-ID: To: Ben Campbell Cc: Peter Saint-Andre , Adam Roach , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org Content-Type: multipart/alternative; boundary="001a1142637829567c0568f7bb27" Archived-At: X-Mailman-Approved-At: Tue, 03 Apr 2018 13:41:54 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:41:33 -0000 --001a1142637829567c0568f7bb27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell wrote: > > > > On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre > wrote: > > > > On 4/3/18 12:27 PM, Suhas Nandakumar wrote: > >> Just to complete, ice-bis doesn=E2=80=99t normatively reference ice-si= p-SDP > >> draft when it moved to using =E2=80=9Cusages =E2=80=9C indirections fo= r signaling > protocols. > >> > >> > >> Trickle ice can use similar approach and refer to trickle-sip as usage > >> for trickle. > > > > It already does. That's why we pulled all the SDP/SIP stuff out of > > draft-ietf-ice-trickle. > > I assume Suhas meant separating the SDP stuff from the SIP stuff. (I also > assume he will correct me if I am wrong.) > > That's right Ben .. I was just thinking minimal localized changes (thus small time to get new draft done) and then asking trickle, trickle-sip to refer to the new one. (work done to refer is much smaller for these drafts that are at the very end of approval journey) I do agree with Adam, no matter what version of the proposal we pick, there is some work that needs to be done and we should do it. > Thanks, > > Ben. > > --001a1142637829567c0568f7bb27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell <ben@nostrum.com> wrote:


> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre <stpeter@mozilla.com> wrote:
>
> On 4/3/18 12:27 PM, Suhas Nandakumar wrote:
>> Just to complete, ice-bis doesn=E2=80=99t normatively reference ic= e-sip-SDP
>> draft when it moved to using =E2=80=9Cusages =E2=80=9C indirection= s for signaling protocols.
>>
>>
>> Trickle ice can use similar approach and refer to trickle-sip as u= sage
>> for trickle.
>
> It already does. That's why we pulled all the SDP/SIP stuff out of=
> draft-ietf-ice-trickle.

I assume Suhas meant separating the SDP stuff from the SIP stuff. (I= also assume he will correct me if I am wrong.)


That's right Ben .. I was just thi= nking minimal localized changes (thus small time to get new draft done) and= then asking trickle, trickle-sip to=C2=A0
refer to the new one. = (work done to refer is much smaller for these drafts that are at the very e= nd of approval journey)

I do agree with Adam, no m= atter what version of the proposal we pick, there is some work that needs t= o be done and we
should do it.
=C2=A0
=C2=A0<= /div>
Thanks,

Ben.


--001a1142637829567c0568f7bb27-- From nobody Tue Apr 3 13:52:42 2018 Return-Path: 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 8DDCD12D873 for ; Tue, 3 Apr 2018 13:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kjPuSmCepCV0 for ; Tue, 3 Apr 2018 13:52:39 -0700 (PDT) Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (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 5DD3912706D for ; Tue, 3 Apr 2018 13:52:39 -0700 (PDT) Received: from smtp16.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 66C6D5BCA; Tue, 3 Apr 2018 16:52:36 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 03D5658A3; Tue, 3 Apr 2018 16:52:35 -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:587 (trex/5.7.12); Tue, 03 Apr 2018 16:52:36 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_33F95179-B256-4E28-8E6B-45D6CB7729EA" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Tue, 3 Apr 2018 14:52:34 -0600 Cc: RTCWeb IETF Message-Id: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> <443FC3E5-891C-49BB-90A1-C3139D3C0655@iii.ca> To: Tim Panton X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:52:41 -0000 --Apple-Mail=_33F95179-B256-4E28-8E6B-45D6CB7729EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 3, 2018, at 3:14 AM, T H Panton wrote: >=20 > In case anyone thinks this issue will go away if we ignore it: >=20 > = https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_l= eak_ip_addresses/ = >=20 > T. I=E2=80=99d phrase that as 77% of VPNs are not broken and here is a = simple WebRTC test to find out if your VPN is totally broken. Note that = if it is broken for WebRTC, is is also broken for non WebRTC apps like = Skype. I will not that since that article was published, the guys that = did the tests has updated the data at https://voidsec.com/vpn-leak/ and = now only 83% of the VPN are not broken. It clear that VPN providers are = fixing this problem.=20 --Apple-Mail=_33F95179-B256-4E28-8E6B-45D6CB7729EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 3, 2018, at 3:14 AM, T H Panton <thp@westhawk.co.uk> = wrote:

In case anyone thinks this issue = will go away if we ignore it:

https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vp= ns_tested_leak_ip_addresses/

T.

I=E2=80=99d phrase that as 77% of VPNs are not broken and = here is a simple WebRTC test to find out if your VPN is totally broken. = Note that if it is broken for WebRTC, is is also broken for non WebRTC = apps like Skype. I will not that since that article was published, the = guys that did the tests has updated the data at https://voidsec.com/vpn-leak/ and now only 83% of the VPN = are not broken. It clear that VPN providers are fixing this = problem. 


= --Apple-Mail=_33F95179-B256-4E28-8E6B-45D6CB7729EA-- From nobody Tue Apr 3 21:59:21 2018 Return-Path: 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 A5A6F126DED for ; Tue, 3 Apr 2018 21:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 xccvNQ9DhTal for ; Tue, 3 Apr 2018 21:59:16 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B57A126DC2 for ; Tue, 3 Apr 2018 21:59:16 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id v134so11614247vkd.10 for ; Tue, 03 Apr 2018 21:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wzRNTUFjjojIqhpa0PCLclJSBKBIUNnZuBpJhlQDIrM=; b=u+ssgBNS2T10b2Jy2m6Ht3PTfLew6pR24ow6MGktxpUREo72+3dT934Cuxl/dlNmn2 /GWcD5DkRqe2Jvt7Ryp5CSdV5/bWJ2liyLVRy54Mq4YNg4Lb6oWw8Wrh9K1lwWfLeFDr i0B7mX/T0A+g6Hx4vKRwZE/wCXxRSKtKNIf9G+856+kP1k8g5NhvysD+2m/hEp4hPkbN mDJ36QaJugPi/ynAlH+b4KNJMUhwq61q+k7s1V+oZRIx40pXeQXsk5qs1lEDhlVlchKn Dw1z9ixHEkdap+SAEVD9e5V+euHUhlnT4JmrVWM638+N3TxM7J9t3kjQAEan/bK5m5V2 jQUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wzRNTUFjjojIqhpa0PCLclJSBKBIUNnZuBpJhlQDIrM=; b=GHjMoWsxUgi2C3j4V4eywQ6U3qjRt6y9jb9Y/QSCrG4GYjN66KQP/GrFyPCOrerSLr 9jU1Gy9RiTVUpJf8vMp/9UoF1fL02xSwH7UyC/YdczZUMi7/WgwkMnNHt9p8uAAl+LKe Tl64JtNP/cs2++uVNiI8d6LmFM1EHgX0fW5d7gmYibOD69dHxJUecHIh8uCagu2CwsQw /qpzriOLYFpTyjhAoXy0IaX5qO3abTnNjnQzKKjeR2sRtI78+f4s1ZfnbQskKrPHWLFD F2Yy06H+OhA1aYHnF1WkTAK9Qxd9TckYD9wQT/Cd05Y+MCdOL6ouP89B9Nx7DAD46zrP LKkg== X-Gm-Message-State: ALQs6tAjdAKJzFUfVzhhv20ikGJfz0ei2Q/b6lCDEQ1btmvOQiQ75j8Z 488lGZT2QYpNIYXY/ZtEC35Bu6zrlT6ODnpFDFD2Mw== X-Google-Smtp-Source: AIpwx48LH/MlM9qs7fVQSkXgt+sGZnxv1oJr5khLttWngfnfLxUAKKmfbMKYD+e5iY4Odk28jCEUJIdJtYzucY7p0FY= X-Received: by 10.31.158.207 with SMTP id h198mr8853131vke.165.1522817954831; Tue, 03 Apr 2018 21:59:14 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <03D3C806-B93F-4CD0-B57B-507B07E869A0@westhawk.co.uk> <540AF425-A798-41BB-8C22-9F697DF46117@westhawk.co.uk> <562af54d-9fcd-48c3-5709-6c8fa469e995@cs.tcd.ie> <8D1E1BA7-9BDE-4302-A698-B1C3E4686F12@westhawk.co.uk> <8d528cc5-84d9-c0cf-be5a-19e836f7ca89@cs.tcd.ie> <443FC3E5-891C-49BB-90A1-C3139D3C0655@iii.ca> In-Reply-To: From: Justin Uberti Date: Wed, 04 Apr 2018 04:59:04 +0000 Message-ID: To: andyhutton.ietf@gmail.com Cc: Philipp Hancke , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a1142793a4208800568feaf85" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 04:59:19 -0000 --001a1142793a4208800568feaf85 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 3, 2018 at 7:56 AM Andy Hutton wrote: > On 3 April 2018 at 14:17, Philipp Hancke > wrote: > > Am 03.04.2018 um 11:14 schrieb T H Panton: > >> > >> In case anyone thinks this issue will go away if we ignore it: > >> > >> > >> > https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/ > >> < > https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/ > > > > > > > > It turned out the issue in this case is > > a) browser extensions that add a proxy server calling themselves a "VPN" > > b) said browser extensions being unaware of the Chrome Extension API to > set > > mode 4 which prevents UDP from being used if a proxy server is set. > > > > The reference to mode 4 forced me to read that part of the draft again > and now I have a question: > > In the description of mode 4 > *https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-06#section-5.2) > what is meant by "or the WebRTC implementation does not support UDP > proxying"? > > Does "UDP Proxying" refer to the return proxy mechanism, a network > specific TURN server, or something else? > UDP proxying refers to any technique that allows the browser to tunnel UDP through a proxy, which would include RETURN, and possibly other types of proxies (QUIC?) in the future. --001a1142793a4208800568feaf85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Apr 3, 2018 at 7:56 AM Andy Hutton <andyhutton.ietf@gmail.com> wrote:
On 3 April 2018 at 14:17, Philipp Hancke <fippo@goodadvice.pages.de= > wrote:
> Am 03.04.2018 um 11:14 schrieb T H Panton:
>>
>> In case anyone thinks this issue will go away if we ignore it:
>>
>>
>> = https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_le= ak_ip_addresses/
>> <https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_teste= d_leak_ip_addresses/>
>
>
> It turned out the issue in this case is
> a) browser extensions that add a proxy server calling themselves a &qu= ot;VPN"
> b) said browser extensions being unaware of the Chrome Extension API t= o set
> mode 4 which prevents UDP from being used if a proxy server is set. >

The reference to mode 4 forced me to read that part of the draft again
and now I have a question:

In the description of mode 4
*https://tools.ietf.org/html= /draft-ietf-rtcweb-ip-handling-06#section-5.2)
what is meant by "or the WebRTC implementation does not support UDP proxying"?

Does "UDP Proxying" refer to the return proxy mechanism, a networ= k
specific TURN server, or something else?

UDP proxying refers to any technique that allows the browser to tunnel UD= P through a proxy, which would include RETURN, and possibly other types of = proxies (QUIC?) in the future.

--001a1142793a4208800568feaf85-- From nobody Wed Apr 4 09:18:00 2018 Return-Path: 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 8619612DA6C for ; Wed, 4 Apr 2018 09:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 mYIeQXW5FrLV for ; Wed, 4 Apr 2018 09:07:42 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD2312DA49 for ; Wed, 4 Apr 2018 09:07:42 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id p139so2951140iod.0 for ; Wed, 04 Apr 2018 09:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hDer+iK/tTTmFkzy+VFVYo69/yS2Rg4C9pWlrPu+IRo=; b=PBN2MpOBfwUH1/d5uYpYZBmIv2hovc7WCzxrRg6j5tu+B39u3elJyXnrZFUvQuCA0d MwkVEwuVxbsQ/TWl+Ff2EchuhfIKu/6EZcsv6peYFHgN7Rj6SoWuZcMJtAgEbqq3sdL5 CW8HpQG8/HQXotEvxGEekBje8um3F3LMEptKs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=hDer+iK/tTTmFkzy+VFVYo69/yS2Rg4C9pWlrPu+IRo=; b=jvVvZjpFLAQlR8yef+gwMmsoaP30PB2299fWwivTQfQm8Hdb+OUA1cwCjID22PUTNH jO3Os2r+0qvkziNDbWnwF+C+QOJUnd3ntSeJ7fyRn3QjP3vDhTZtW3wxSJ0wqCrRtG+x Q2JSRZTqWld0cw37VkRcB8p/o495blJxpP+D9NGs80yeJzkVneOzvA+EmWEZC/mCPY6P fthSbwDiN3wCGE8tC2qHzlIyU7XwDbCJP1vyb5v5niQnhPugKAYpZxVGDuqz6lNL0wAb XIWpwKILvJ4c8RWaX75b6qdfgeNlc1v2dWTDiLzXcaFa41x+QfGsZB0M5NdixO7B8BYy SNFw== X-Gm-Message-State: ALQs6tAAJdGnJXOn9EgIu9v7NDkJE/K4bS6BheQJ+cITlR6QWYcaJDzM OvhqBsYTqNtgjkwuaQ/A+qJRZA== X-Google-Smtp-Source: AIpwx49sQXx0mKcljzSHtJLJRVizaY1/+L80TqEY5cSYMIEySDNYxjphzP7KO0n71Q8nDjIqIdcuNQ== X-Received: by 10.107.179.84 with SMTP id c81mr15534381iof.99.1522858061845; Wed, 04 Apr 2018 09:07:41 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id t134-v6sm2518518itt.43.2018.04.04.09.07.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 09:07:40 -0700 (PDT) To: Suhas Nandakumar , Ben Campbell Cc: Adam Roach , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Wed, 4 Apr 2018 10:07:39 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 04 Apr 2018 09:17:59 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:07:44 -0000 On 4/3/18 2:41 PM, Suhas Nandakumar wrote: > > > On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell > wrote: > > > > > On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre > wrote: > > > > On 4/3/18 12:27 PM, Suhas Nandakumar wrote: > >> Just to complete, ice-bis doesn’t normatively reference ice-sip-SDP > >> draft when it moved to using “usages “ indirections for signaling protocols. > >> > >> > >> Trickle ice can use similar approach and refer to trickle-sip as usage > >> for trickle. > > > > It already does. That's why we pulled all the SDP/SIP stuff out of > > draft-ietf-ice-trickle. > > I assume Suhas meant separating the SDP stuff from the SIP stuff. (I > also assume he will correct me if I am wrong.) > > > That's right Ben .. I was just thinking minimal localized changes (thus > small time to get new draft done) and then asking trickle, trickle-sip to  > refer to the new one. (work done to refer is much smaller for these > drafts that are at the very end of approval journey) > > I do agree with Adam, no matter what version of the proposal we pick, > there is some work that needs to be done and we > should do it. These documents are on the telechat tomorrow. Are we proposing to delay consideration by the IESG while we get this mess sorted out? ;-) Peter From nobody Wed Apr 4 10:22:39 2018 Return-Path: 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 B061D129C5D; Wed, 4 Apr 2018 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RyDJ3mfpGmur; Wed, 4 Apr 2018 09:47:32 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16AE120724; Wed, 4 Apr 2018 09:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2707; q=dns/txt; s=iport; t=1522860452; x=1524070052; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CVGDyZk8+h7fHipLl8NjZBJdmUDeJOLp3CPEr0rjGj4=; b=I4eahyy6kCdgc+2ssoVWVUnR85LqbwBKhkjiBIjFayh9ZQLsbvBPMCZf QfNpYcO9jfnIu11qw/9loM+vhCL0US4v0o7oFANSACqenXq91RorKNCCj Q/cgXK57jWN9RLHnUMeSYb/dblbl10HQoU47QyiYuY2uisU4A+R4sEC++ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgCAAMVa/5RdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdYFQKAqYXYMDjXGEZIF6C4UDAoRAITYWAQIBAQEBAQE?= =?us-ascii?q?CbCiFIwZ5EAIBCAQKLQQHMhQRAgQOBRSEFWSuH4hCgiWHYoITgQwigmKIH4I?= =?us-ascii?q?kApc+CAKOL4w8j1YCERMBgSQBIwYrgVJwFWQBghiCSI4Gb4xXgRcBAQ?= X-IronPort-AV: E=Sophos; i="5.48,407,1517875200"; d="scan'208,217"; a="93647902" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 16:47:31 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w34GlUtF022110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Apr 2018 16:47:30 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 4 Apr 2018 12:47:30 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1320.000; Wed, 4 Apr 2018 12:47:30 -0400 From: "Cullen Jennings (fluffy)" To: Eric Rescorla CC: Roman Shpount , Ben Campbell , "Adam Roach" , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , "Flemming Andreasen (fandreas)" , "RTCWeb IETF" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [Ice] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2gFmEK6jl7hIUqOkWqvx/vbz6PvhV+AgAAIEACAAAg0m////QaAgAGC0AA= Date: Wed, 4 Apr 2018 16:47:30 +0000 Message-ID: <2B936029-9DC7-491C-893F-AE6D05723E4B@cisco.com> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.228.210] Content-Type: multipart/alternative; boundary="_000_2B9360299DC7491C893FAE6D05723E4Bciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 04 Apr 2018 10:22:38 -0700 Subject: Re: [rtcweb] [Ice] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:47:34 -0000 --_000_2B9360299DC7491C893FAE6D05723E4Bciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 3, 2018, at 11:43 AM, Eric Rescorla > wrote: I want to do whatever is necessary to remove the normative dependency from = JSEP to SIP -Ekr I think a big part of the RTCWeb/WebRTC community would strongly object to = JSEP normatively depending on SIP. --_000_2B9360299DC7491C893FAE6D05723E4Bciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <929464B6EA23234BB72F61487F45C971@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

On Apr 3, 2018, at 11:43 AM, Eric Rescorla <ekr@rtfm.com> wrote:


I want to do whatever is necessary to remove the normative dependency from = JSEP to SIP

-Ekr


I think a big part of the RTCWeb/WebRTC community would str= ongly object to JSEP normatively depending on SIP. 
--_000_2B9360299DC7491C893FAE6D05723E4Bciscocom_-- From nobody Wed Apr 4 10:22:43 2018 Return-Path: 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 6647B127978 for ; Wed, 4 Apr 2018 10:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 VoPlgj9TEFij for ; Wed, 4 Apr 2018 10:06:06 -0700 (PDT) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4295E12D94D for ; Wed, 4 Apr 2018 10:05:56 -0700 (PDT) Received: by mail-pl0-x22d.google.com with SMTP id c21-v6so11297709plz.10 for ; Wed, 04 Apr 2018 10:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C6loMDHa8scYgqYof7mziGVsZau/p22LZWGmKOM1gOI=; b=TFTK2+ap0548gFGpjVT+s7j/8rLM+K/7SST/b2+aKn1NbF7Fc+xPV4OYqRPeNYdyhx AEuZbHkauKK+AQ9UjOBFEUv1Dflq7eCrb5J0Jbi0aRWAmQM4DlPg5ns1OCCkdjYQSTPz D0kVA3HgscF7RakPY4z9horgDkDdAS4ceaf+F7lHRC3M+94yAfwiAV4Lo7ZkdSCKbhAS hdukphl83Jyezd2cTac/zgtcRrKVjn+ApngAVAR43bY8XvvvdfE2cSKJnLww+EUczatX 9KcNAInsQ1hjQ6fJ65VGKfKz36ygh3YhXGFLogsnyiuQur6+BqgiKClV8+GlSW2ndaTs FKGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C6loMDHa8scYgqYof7mziGVsZau/p22LZWGmKOM1gOI=; b=lRjfhx1caiyMZxlr6G5H093y+e6Qcx1/LgsELAUgVBlZLWnR8kfStd2NMcFZUfB1IB 318mJtZM59ngDq3sITer4RprqevojutqQaqihm2pGMWdaLRIzCt/87SeZ3PU+XDxl9GF jISfAF13vV2RWmJBUNge4YMYQZchQLXcwv1mhuLtJ7BIDWDq8WrnPDTDKIuw7cak6d4w uRWnk6Aa62Oo9A4dti4u34IenMC6S4MNEaa1wkMx0jfH9ns2BOBh0JXGkS/xvWzMHS2/ G6Mz/ex6bqh+qDq7X61ipVy1DulaSAILwnuJ15kRULyZa0p13YL+YdWBgCUl+dzfQFRG VLKw== X-Gm-Message-State: AElRT7H2xzFlqIs5YDxwHRoT1KcqRhbCT/dWPmC4q1bXiUe5X2p2cnrI U5tlXbaaaS4kW/QAKD76zap0ew== X-Google-Smtp-Source: AIpwx48j9yQmvKSfN3T72wPsoZZZHlUi8xtnMgQMXzrCYJhFAZcyswcz4uTlx7OMQsZ89JFcZjE5OQ== X-Received: by 10.99.114.1 with SMTP id n1mr12510209pgc.107.1522861555922; Wed, 04 Apr 2018 10:05:55 -0700 (PDT) Received: from mail-pl0-f48.google.com (mail-pl0-f48.google.com. [209.85.160.48]) by smtp.gmail.com with ESMTPSA id w17sm4209785pfa.125.2018.04.04.10.05.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 10:05:55 -0700 (PDT) Received: by mail-pl0-f48.google.com with SMTP id c21-v6so11297593plz.10; Wed, 04 Apr 2018 10:05:54 -0700 (PDT) X-Received: by 2002:a17:902:7185:: with SMTP id b5-v6mr19348304pll.221.1522861554782; Wed, 04 Apr 2018 10:05:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.79 with HTTP; Wed, 4 Apr 2018 10:05:54 -0700 (PDT) In-Reply-To: <2B936029-9DC7-491C-893F-AE6D05723E4B@cisco.com> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <2B936029-9DC7-491C-893F-AE6D05723E4B@cisco.com> From: Roman Shpount Date: Wed, 4 Apr 2018 13:05:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Cullen Jennings (fluffy)" Cc: Eric Rescorla , Ben Campbell , Adam Roach , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , "Flemming Andreasen (fandreas)" , RTCWeb IETF , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Content-Type: multipart/alternative; boundary="00000000000003d981056908d6c2" Archived-At: X-Mailman-Approved-At: Wed, 04 Apr 2018 10:22:38 -0700 Subject: Re: [rtcweb] [Ice] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:06:07 -0000 --00000000000003d981056908d6c2 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 4, 2018 at 12:47 PM, Cullen Jennings (fluffy) wrote: > > On Apr 3, 2018, at 11:43 AM, Eric Rescorla wrote: > > I want to do whatever is necessary to remove the normative dependency from > JSEP to SIP > > > I think a big part of the RTCWeb/WebRTC community would strongly object to > JSEP normatively depending on SIP. > Do you have any issues with dependency on RFC5245 and the portion of it which went into draft-mmusic-ice-sip-sdp? Both define SIP procedures in addition to offer/answer. We are kind of dealing with the same thing here. Other drafts, like mmusic-dtls-sdp have SIP consideration sections in them. It did not seem to cause any issues either. As I have mentioned earlier, I think, trickle-ice-sip should internally clearly identify generic offer/answer SDP procedures and SIP specific considerations. Once it is done it would be no different then all the other offer/answer drafts we put together recently. _____________ Roman Shpount --00000000000003d981056908d6c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 4, 2018 at 12:47 PM, Cu= llen Jennings (fluffy) <fluffy@cisco.com> wrote:

On Apr 3, 2018, at 11:43 AM, Eric Rescorla <ekr@rtfm.com> wrote:

I want to do whatever is necessary to remove the normative dependency from = JSEP to SIP

I think a big part of the RTCWeb/WebRTC community would strongl= y object to JSEP normatively depending on SIP.=C2=A0

Do you have any iss= ues with dependency on=20 RFC5245 and the portion of i= t which went into draft-mmusic-ice-sip-sdp? Both define SIP procedures in addition to offer/a= nswer. We are kind of dealing with the same thing here. Other drafts, like = mmusic-dtls-sdp have SIP consideration sections in them. It did not seem to= cause any issues either.

As I ha= ve mentioned earlier, I think,=C2=A0 trickle-ice-sip should internally clea= rly identify generic offer/answer SDP procedures and SIP specific considera= tions. Once it is done it would be no different then all the other offer/an= swer drafts we put together recently.
<= div class=3D"gmail_signature">_____________
Roman Shpount

--00000000000003d981056908d6c2-- From nobody Wed Apr 4 12:43:45 2018 Return-Path: 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 2A73D126C22; Wed, 4 Apr 2018 10:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 0pgBW-Ku13g9; Wed, 4 Apr 2018 10:23:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3F112D775; Wed, 4 Apr 2018 10:23:11 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w34HN5U0025759 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Apr 2018 12:23:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6382D4F8-A6C7-47D0-BE19-DAA943570D77"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 4 Apr 2018 12:23:04 -0500 In-Reply-To: Cc: Suhas Nandakumar , Adam Roach , mmusic WG , mmusic-chairs@ietf.org, "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , draft-ietf-mmusic-trickle-ice-sip@ietf.org To: Peter Saint-Andre References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-Mailman-Approved-At: Wed, 04 Apr 2018 12:43:40 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:23:14 -0000 --Apple-Mail=_6382D4F8-A6C7-47D0-BE19-DAA943570D77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre = wrote: >=20 > On 4/3/18 2:41 PM, Suhas Nandakumar wrote: >>=20 >>=20 >> On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell > > wrote: >>=20 >>=20 >>=20 >>> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre > wrote: >>>=20 >>> On 4/3/18 12:27 PM, Suhas Nandakumar wrote: >>>> Just to complete, ice-bis doesn=E2=80=99t normatively reference = ice-sip-SDP >>>> draft when it moved to using =E2=80=9Cusages =E2=80=9C indirections = for signaling protocols. >>>>=20 >>>>=20 >>>> Trickle ice can use similar approach and refer to trickle-sip as = usage >>>> for trickle. >>>=20 >>> It already does. That's why we pulled all the SDP/SIP stuff out of >>> draft-ietf-ice-trickle. >>=20 >> I assume Suhas meant separating the SDP stuff from the SIP stuff. = (I >> also assume he will correct me if I am wrong.) >>=20 >>=20 >> That's right Ben .. I was just thinking minimal localized changes = (thus >> small time to get new draft done) and then asking trickle, = trickle-sip to >> refer to the new one. (work done to refer is much smaller for these >> drafts that are at the very end of approval journey) >>=20 >> I do agree with Adam, no matter what version of the proposal we pick, >> there is some work that needs to be done and we >> should do it. >=20 > These documents are on the telechat tomorrow. Are we proposing to = delay > consideration by the IESG while we get this mess sorted out? ;-) Hi Peter, I currently plan to leave it on. We may discuss a way forward on the = telechat. Also, I=E2=80=99d like to get feedback on the rest of the = draft(s) from the other ADs sooner than later. Thanks! Ben. --Apple-Mail=_6382D4F8-A6C7-47D0-BE19-DAA943570D77 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrFCfgACgkQgFZKbJXz 1A3/VBAAqDvaaL3WVTzh4ooufivb/cH+C7BHR6W3v1FcnQAVsfQR8XT4WysJIm38 Ks7llDVLN3XtybXBrGeTM6VALocI/XuYS2Rqyr5q34WnQhcdJA5RDvKIrV+qBMrU sPFmjX85NzRwJv3zGlXUsjdSjMysrdySqyBqr686g/pLMufUXmgAxoKppyNQWHBs lhSCXjvoJKdDxLvnny34e7hIM2/IQvrA01R1ThZsbg0a3ppSnc1aUbpxtHA41Pq3 EINCTjT4idSMi1MijCCGg29yITaLizAGbZi+gwIG0AeVJcguOYDK0u5XsSkBCD5F QML8MOZri0OjM5ss3vNr9NspcrUYxc3MJcyP1KN7IgAljP258ygTuwksgwcUZqU4 NnG3UguWfxYNDsUUM6vnap6g3oYIQHrk4r6XKEwOKkFjs19Owu0PZc4Ipn0RTmzn 7ZRiR5Qsme9RPZeFwsteiYLtxPtciplvMny0QdlvdSojVEwAK+5Be7T52oovx8tS NzcVOzQZI5/Q10OZoQ0iiWEojvHWQNsbGkSDxiGy+LSbgeBEJos3PbAbFox5b/zd gvNyhKMNIIp/rTT+xrn/GNFGk79vIIbHMJGqOqKIspX9x48jwJO1FSZVFHNeApYV SQkn3/s+i7RWNFckWL/tvE09dC6MGLZbE3nHX8V9IXpx4sn1lZU= =sfbx -----END PGP SIGNATURE----- --Apple-Mail=_6382D4F8-A6C7-47D0-BE19-DAA943570D77-- From nobody Tue Apr 10 12:34:52 2018 Return-Path: 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 51B2B12DA6C for ; Tue, 10 Apr 2018 12:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 KN5fuXWYFtsj for ; Tue, 10 Apr 2018 12:34:49 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A2012D778 for ; Tue, 10 Apr 2018 12:34:49 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id d201so7753635vke.0 for ; Tue, 10 Apr 2018 12:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TSqAzO2YQ2QRvA8XNT8uDkGkKBdhAsR29ifM+n5euWU=; b=Qz9AP+65nyNzuDMvb8fqbJjUrmr08lLGu8BMECwhaK6uYznDzqsc71HclcCcjp0OvC +VeM/qlUs0vwTkxFFE4BFXrulSJZkGQ1DH0pCGTXIPvsiY76jxx9sQinSJ//FYdmRMZt oqEEYCDOgNR4g72AUsmVDCzTMyEmroW7n479JXpgbYKInd0L5uq01kolcdhslWI9mg3t B3fjGsn9QXTK3rQKVKJMLLUJ/WrDJm8SIutW9orojClcOyDdUC0vEauXl0XHA4udOlEO XWUyMAvqrNqofpAdMQ4kh2jM8Om7lDfH8lD9/Kp7dN8sN8IuoyHLRMZKKmBbwFSGrJsJ vHsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TSqAzO2YQ2QRvA8XNT8uDkGkKBdhAsR29ifM+n5euWU=; b=q4IZLtWGfn3RQRCFTIyhBzawKM00oGyyiBpLs1X8JpfmUh28ccf7PvaT2bxGU/h8q+ Etph3PZq2SiQqVE7jENd4V43929XJFvNgaDJQvVcGfMN7T/9Q5R+yyRhYwnZsk9Mjsbw a73qFKkan1vpXlX4kZSqKkSgmgHfrycDGi13OTiqfN8xOdZVmWcDP9xOvDsxDVPjz0Dt QWx7XB8cG8pk80OrH9vYuzuAGHoyyr24uEtY7A8iBEQlvKih9hWOfBTEuKPX16Kz5qss DToEVOMoLF8JVNn8R9NMBdAwdalxG497iSMHx/BhKWf2E7PscNdbne3f6LNiCJaEEZTU Taxg== X-Gm-Message-State: ALQs6tDitkbLRAxmjDBFwi0wKY5DO8Gc+tm/N+KH4r/a0CnaUWtmyIWx p+cBgl6PCfHHcVomsEokGmZ/QArEbjzkefAKoNdL5Pz6dWg= X-Google-Smtp-Source: AIpwx4+SVdwzg2k9f+vpSKs7kvfguO0+crd3/J6Us+9prOE08L87+M7SIw8x+XyYvbVwpgYk65GzdoMLCHbloa8Z398= X-Received: by 10.31.4.129 with SMTP id 123mr1342561vke.122.1523388887405; Tue, 10 Apr 2018 12:34:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Tue, 10 Apr 2018 12:34:46 -0700 (PDT) From: Taylor Brandstetter Date: Tue, 10 Apr 2018 12:34:46 -0700 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="001a114298727da7ae0569839dd8" Archived-At: Subject: [rtcweb] What happens to buffered data when closing a DataChannel? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 19:34:51 -0000 --001a114298727da7ae0569839dd8 Content-Type: text/plain; charset="UTF-8" Recently on a chromium bug , there's been some discussion about the data channel closing procedure. The main question seems to be: what happens to messages that have been enqueued but not yet sent? rtcweb-data-protocol says: [RFC6525] also guarantees that all the messages are delivered (or > abandoned) before the stream is reset. > > Which I believe refers to this step for performing a reset: C2: The sender has either no outstanding TSNs or considers all > outstanding TSNs abandoned. > > However: what about messages that have been enqueued but haven't yet generated TSNs? Is their delivery guaranteed? Or from the perspective of the JS API: can an application assume that after calling "close", *all* buffered data will be sent? Or does it need to wait until bufferedAmount goes to 0 to be safe? And a secondary question, if we decide "buffered data must be sent": does this apply to both sides, or only the side initiating the closure? Note that implementations are currently inconsistent on this point; Chrome ensures all buffered data is sent (from the side initiating the closure) while Firefox doesn't. --001a114298727da7ae0569839dd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Recently on a chromium bug, there's been some = discussion about the data channel closing procedure.

The= main question seems to be: what happens to messages that have been enqueue= d but not yet sent?

rtcweb-data-protocol says:

   [RFC6525] also guarantees that all the messages are =
delivered (or
   abandoned) before the stream is reset.

=
Which I believe refers to this step for performing a reset:
= 
   C2:  The sender has either no outstan=
ding TSNs or considers all
        outstanding TSNs abandoned.

H= owever: what about messages that have been enqueued but haven't yet gen= erated TSNs? Is their delivery guaranteed?

Or from= the perspective of the JS API: can an application assume that after callin= g "close", all buffered data will be sent? Or does it need= to wait until bufferedAmount goes to 0 to be safe?

And a secondary question, if we decide "buffered data must be sent&q= uot;: does this apply to both sides, or only the side initiating the closur= e?

Note that implementations are currently inconsi= stent on this point; Chrome ensures all buffered data is sent (from the sid= e initiating the closure) while Firefox doesn't.
--001a114298727da7ae0569839dd8-- From nobody Tue Apr 10 12:56:08 2018 Return-Path: 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 AB77212DA4A for ; Tue, 10 Apr 2018 12:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 ROztBhhgJSsr for ; Tue, 10 Apr 2018 12:56:03 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DA6127876 for ; Tue, 10 Apr 2018 12:56:03 -0700 (PDT) Received: from [IPv6:2003:cd:6f00:5e00:bced:c00f:b0a3:ac4b] (p200300CD6F005E00BCEDC00FB0A3AC4B.dip0.t-ipconnect.de [IPv6:2003:cd:6f00:5e00:bced:c00f:b0a3:ac4b]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id CB2D9721E281A; Tue, 10 Apr 2018 21:55:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Michael Tuexen In-Reply-To: Date: Tue, 10 Apr 2018 21:55:58 +0200 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <315C4164-5007-4055-AACC-1130EBDB3962@lurchi.franken.de> References: To: Taylor Brandstetter X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] What happens to buffered data when closing a DataChannel? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 19:56:07 -0000 > On 10. Apr 2018, at 21:34, Taylor Brandstetter = wrote: >=20 > Recently on a chromium bug, there's been some discussion about the = data channel closing procedure. >=20 > The main question seems to be: what happens to messages that have been = enqueued but not yet sent? >=20 > rtcweb-data-protocol says: >=20 > [RFC6525 > ] also guarantees that all the messages are delivered (or > abandoned) before the stream is reset. That is correct. >=20 >=20 > Which I believe refers to this step for performing a reset: >=20 > C2: The sender has either no outstanding TSNs or considers all > outstanding TSNs abandoned. No, this refers to the resetting of the SSN and TSN. This is not used by = WebRTC. WebRTC only resets outgoing streams, which is described by https://tools.ietf.org/html/rfc6525#section-5.1.2 >=20 >=20 > However: what about messages that have been enqueued but haven't yet = generated TSNs? Is their delivery guaranteed? The above text doesn't apply to any procedure used in WebRTC> >=20 > Or from the perspective of the JS API: can an application assume that = after calling "close", all buffered data will be sent? Or does it need = to wait until bufferedAmount goes to 0 to be safe? >=20 > And a secondary question, if we decide "buffered data must be sent": = does this apply to both sides, or only the side initiating the closure? This has never been clear to me. When I asked people, most of the times = I got a response indicating that it should do the same as WebSockets... You should also consider the backwards direction, since a data channel = is bidirectional. So A calls close on a data channel. If you want to provide a reliable = shutdown procedure, you would make sure all messages buffered above the SCTP stack would be provided = to the SCTP stack and then you would reset the outgoing stream. Once this stream reset is received = by B you would trigger the onclose() callback, I guess. Now you would not accept any send() = calls on B anymore, I guess. But you might have messages buffered above SCTP, which you should = provide to the SCTP stack and then reset the corresponding outgoing stream. This would imply that you = still call ondata() on side A, even after close until the stream reset has been received and = you would call onclose(). But this is not as defined for WebSockets. I think you discard messages = received after close() has been called... Best regards Michael >=20 > Note that implementations are currently inconsistent on this point; = Chrome ensures all buffered data is sent (from the side initiating the = closure) while Firefox doesn't. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Apr 10 12:56:22 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0112E058 for ; Tue, 10 Apr 2018 12:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523390171; bh=1gX2U5z2HZvMypylWAbmX1EIBnznujfKhZv/2AWyi9k=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=MelSnox47kChCz4Lta0RRqEf3nmIm8D+QBo98M9cnVK4aBBXoxceaxvgzAANGJDPe zNIxpVshUtyt/shFoACTuH0BUr7Ux1UP8LDwQP1M54OjJr4rQ+FtsLlRkFFK+dbiML mdU2zMno9t8EGJCa4dpgStMclcoLWkGPSflldWhw= X-Mailbox-Line: From michael.tuexen@lurchi.franken.de Tue Apr 10 12:56:10 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F03F612E03C for ; Tue, 10 Apr 2018 12:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523390170; bh=1gX2U5z2HZvMypylWAbmX1EIBnznujfKhZv/2AWyi9k=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=cOwK/11BTrJzPU9V+CRfLFEiP2GvZFHqe8b4+jHg5ZSd+0HZjKwB6WeqRT9xiGEQ9 Odg+PFissD2tBUxVQ0KS5CHFGmN1mJs9+w2mmuHSaVrK8IliQHSa9XQtewrZgbP2mK JA+oicOba6wJAUGh8gUQ42qyUo9t9aMTaYMnzDvM= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE14812E048 for ; Tue, 10 Apr 2018 12:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable 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 9Hyw1QWflb7j for ; Tue, 10 Apr 2018 12:56:07 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC79E127876 for ; Tue, 10 Apr 2018 12:56:03 -0700 (PDT) Received: from [IPv6:2003:cd:6f00:5e00:bced:c00f:b0a3:ac4b] (p200300CD6F005E00BCEDC00FB0A3AC4B.dip0.t-ipconnect.de [IPv6:2003:cd:6f00:5e00:bced:c00f:b0a3:ac4b]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id CB2D9721E281A; Tue, 10 Apr 2018 21:55:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Michael Tuexen In-Reply-To: Date: Tue, 10 Apr 2018 21:55:58 +0200 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <315C4164-5007-4055-AACC-1130EBDB3962@lurchi.franken.de> References: X-Mailer: Apple Mail (2.3445.6.18) To: Taylor Brandstetter Archived-At: Subject: Re: [rtcweb] What happens to buffered data when closing a DataChannel? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 19:56:14 -0000 > On 10. Apr 2018, at 21:34, Taylor Brandstetter = wrote: >=20 > Recently on a chromium bug, there's been some discussion about the = data channel closing procedure. >=20 > The main question seems to be: what happens to messages that have been = enqueued but not yet sent? >=20 > rtcweb-data-protocol says: >=20 > [RFC6525 > ] also guarantees that all the messages are delivered (or > abandoned) before the stream is reset. That is correct. >=20 >=20 > Which I believe refers to this step for performing a reset: >=20 > C2: The sender has either no outstanding TSNs or considers all > outstanding TSNs abandoned. No, this refers to the resetting of the SSN and TSN. This is not used by = WebRTC. WebRTC only resets outgoing streams, which is described by https://tools.ietf.org/html/rfc6525#section-5.1.2 >=20 >=20 > However: what about messages that have been enqueued but haven't yet = generated TSNs? Is their delivery guaranteed? The above text doesn't apply to any procedure used in WebRTC> >=20 > Or from the perspective of the JS API: can an application assume that = after calling "close", all buffered data will be sent? Or does it need = to wait until bufferedAmount goes to 0 to be safe? >=20 > And a secondary question, if we decide "buffered data must be sent": = does this apply to both sides, or only the side initiating the closure? This has never been clear to me. When I asked people, most of the times = I got a response indicating that it should do the same as WebSockets... You should also consider the backwards direction, since a data channel = is bidirectional. So A calls close on a data channel. If you want to provide a reliable = shutdown procedure, you would make sure all messages buffered above the SCTP stack would be provided = to the SCTP stack and then you would reset the outgoing stream. Once this stream reset is received = by B you would trigger the onclose() callback, I guess. Now you would not accept any send() = calls on B anymore, I guess. But you might have messages buffered above SCTP, which you should = provide to the SCTP stack and then reset the corresponding outgoing stream. This would imply that you = still call ondata() on side A, even after close until the stream reset has been received and = you would call onclose(). But this is not as defined for WebSockets. I think you discard messages = received after close() has been called... Best regards Michael >=20 > Note that implementations are currently inconsistent on this point; = Chrome ensures all buffered data is sent (from the side initiating the = closure) while Firefox doesn't. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 11 04:58:20 2018 Return-Path: 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 3FC31120724 for ; Wed, 11 Apr 2018 04:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 R3btZXwHjZsW for ; Wed, 11 Apr 2018 04:58:16 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B91124207 for ; Wed, 11 Apr 2018 04:58:16 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id g8so3593404wmd.2 for ; Wed, 11 Apr 2018 04:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fG50gktLQiuPLynwAjIGTqYlc0UoxQAJkoy4oR5sjDw=; b=bkwXyI8ePIzk+GMpvVltSNlrlLqzztSHqwI/Wx1Cg20fHv1RwvOfz8QhAcu3G2teDn fRdbLfTpaJBB2cgApvrcs8eFKJpH4SPUlowzUnxGv+Vgfgl4S3VEzn4X5KaMn9F/+acM Y1weF2GrVE8Y+Vqa8TZjRE6pDVoxG17nl8DeHLoyNzYR1y70HnRPD5AH2GJONgHLHqUt v3haqk+GTtqIRLzUbmLOBhVsWlt+RrqHCVUC4njaO1+i7naRnNoAg0tMAWJOdVfcUgx/ KG4v8JG7AlVZIum0dk4f8Zr/gkwg0cmsAraFPogqBfQmVbwwc/n0ccnwZkY3Uz0fV8cN INIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:cc:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fG50gktLQiuPLynwAjIGTqYlc0UoxQAJkoy4oR5sjDw=; b=YWEglJCcwupBxCGX5dgzLgKKArSJEbf/2th7B7oyGfCz7gd5ID1IBxah2zYtSBca8Z 64XnuNFZOY+cGh+sC4BuMYdm4q66ubIPuxOGt4qT0JbYhfmcWCCorz4TXOFCpIqc9bTi pcswFOfVALGpXKEuxZMXRV5K9TAk1+4+jhqt2uSaGmJeOpwd5bK4GUDEi3KkcqnymoxJ +mclOS0nntrU0/qYaWSsa6FONfSTeLyU671NO9EPwj+1pxCUKL5tjoXdb+/eUemQrFj4 2KaOJWj0nDYB2KJLQnOr4Xkj418ZBroH8x+p59LY6/DROQtbpm/20BXooJVprW5GObXh M9Jg== X-Gm-Message-State: ALQs6tDAuxup2kTvPXzRjizKhzrKK7hpjAofWWhOOw5OpbiOVemQYulR Of/w60LADCZwdBKeMPBH51Q= X-Google-Smtp-Source: AIpwx4/c1BnjPLBhpa43JK+yQRAHlK+FUIF4SUwcjKIZvawpql++uL2mNFAyPRtJIJtqPDZd5DyCzg== X-Received: by 10.28.128.12 with SMTP id b12mr2313424wmd.148.1523447894543; Wed, 11 Apr 2018 04:58:14 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:3d14:e3e8:2cef:11e2? (p200300CD6F24EB003D14E3E82CEF11E2.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:3d14:e3e8:2cef:11e2]) by smtp.gmail.com with ESMTPSA id j8sm2042195wri.22.2018.04.11.04.58.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 04:58:14 -0700 (PDT) To: rtcweb@ietf.org References: <315C4164-5007-4055-AACC-1130EBDB3962@lurchi.franken.de> From: Lennart Grahl Openpgp: preference=signencrypt Cc: Michael Tuexen , Taylor Brandstetter Message-ID: <4d685978-5a76-c88a-a563-07232ae1cd23@gmail.com> Date: Wed, 11 Apr 2018 13:58:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <315C4164-5007-4055-AACC-1130EBDB3962@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] What happens to buffered data when closing a DataChannel? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 11:58:19 -0000 On 10.04.2018 21:55, Michael Tuexen wrote: >> On 10. Apr 2018, at 21:34, Taylor Brandstetter wrote: >> >> Recently on a chromium bug, there's been some discussion about the data channel closing procedure. >> >> The main question seems to be: what happens to messages that have been enqueued but not yet sent? >> >> rtcweb-data-protocol says: >> >> [RFC6525 >> ] also guarantees that all the messages are delivered (or >> abandoned) before the stream is reset. > That is correct. >> >> >> Which I believe refers to this step for performing a reset: >> >> C2: The sender has either no outstanding TSNs or considers all >> outstanding TSNs abandoned. > No, this refers to the resetting of the SSN and TSN. This is not used by WebRTC. > WebRTC only resets outgoing streams, which is described by > https://tools.ietf.org/html/rfc6525#section-5.1.2 >> >> >> However: what about messages that have been enqueued but haven't yet generated TSNs? Is their delivery guaranteed? > The above text doesn't apply to any procedure used in WebRTC> May I first point out that I've opened an issue on the W3C spec for this topic before: https://github.com/w3c/webrtc-pc/issues/1825 I don't have a strong opinion where to discuss this but it's getting hard to follow. ;) >> Or from the perspective of the JS API: can an application assume that after calling "close", all buffered data will be sent? Or does it need to wait until bufferedAmount goes to 0 to be safe? To compare it with WebSocket: WS ensures that all pending messages are being sent before the WS is closed. And there are undoubtedly common use cases for it, so we should follow that, too. It's pretty clear to me in the draft, so I made a PR to clarify it in the W3C spec as well a week ago: https://github.com/w3c/webrtc-pc/pull/1822 >> And a secondary question, if we decide "buffered data must be sent": does this apply to both sides, or only the side initiating the closure? > This has never been clear to me. When I asked people, most of the times I got a response indicating > that it should do the same as WebSockets... > > You should also consider the backwards direction, since a data channel is bidirectional. > > So A calls close on a data channel. If you want to provide a reliable shutdown procedure, you would > make sure all messages buffered above the SCTP stack would be provided to the SCTP stack and then > you would reset the outgoing stream. Once this stream reset is received by B you would trigger > the onclose() callback, I guess. Now you would not accept any send() calls on B anymore, I guess. > But you might have messages buffered above SCTP, which you should provide to the SCTP stack and > then reset the corresponding outgoing stream. This would imply that you still call ondata() > on side A, even after close until the stream reset has been received and you would call onclose(). > > But this is not as defined for WebSockets. I think you discard messages received after close() > has been called... Indeed. To quote: "When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps: [WSP] 1. If the readyState attribute's value is not OPEN (1), then return." Source: https://html.spec.whatwg.org/multipage/web-sockets.html#feedback-from-the-protocol A WS whose closing procedure has been started will be in the 'closing' state (the same applies to data channels). My opinion: I think we should follow WS and not raise the 'message' event as soon as the channel is not in the 'open' state any more. That leaves whether to send or to discard (if possible - some data may be in flight) pending data on the peer whose channel got closed by the other peer up to the implementation (since all of the messages will be ignored anyway). And it's a very simple clarification in the W3C spec. >> Note that implementations are currently inconsistent on this point; Chrome ensures all buffered data is sent (from the side initiating the closure) while Firefox doesn't. FYI regarding Firefox: People I've spoken to generally agree that Firefox got it wrong but they're waiting for clarification on the spec side, see https://bugzilla.mozilla.org/show_bug.cgi?id=1413198 Cheers Lennart From nobody Wed Apr 11 05:08:15 2018 Return-Path: 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 EC0BA124207 for ; Wed, 11 Apr 2018 05:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mUP5wdYwYEki for ; Wed, 11 Apr 2018 05:08:11 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E07120724 for ; Wed, 11 Apr 2018 05:08:10 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id d19so1539254wre.1 for ; Wed, 11 Apr 2018 05:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:openpgp:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=ctzutNTbXl1G7R2MKiV+nO1cz7i/4y1WdYzXN5W8M9k=; b=KhT3NW29uK4c6IAjkk61DAvzogdxeueiTqxBILFWRFEimx0c+hUpXDpA65SUAh4EPS 0zktiBtUTjAYma1bIIx2WRRIiSsNhKyXtLgk3v84Esme4MruxAA9kn9zwdtatDR1Rzz7 fQ0jAm0EpOA9Ep5H2FVgDvAoqyT6wa06ZFsBtKkeMkG89ewz4l84faGF1luHgbapUDPL 89VRrtdCmPuFGVTsDGUTH7IjKBMAafs1bHDLrM/ZupFKPaltf3DNoH49ppUyGbvYDG4Z 1z/LUSU8Sz3YYG16raWlFtPogorJ7Yrj7F2KSSptn8oYq/iZfNrayKJNWr6mTuNkgOUV /jZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=ctzutNTbXl1G7R2MKiV+nO1cz7i/4y1WdYzXN5W8M9k=; b=WxPcqt4piT6OpFi4SwR6EZH8Qag8RTIapRA2TdpzHUK3Qe9sOtm7Nmz2Sy3YP8zGy2 AK4K/eEfXyViq73QNga4dIvFKurrOtBKsnU+n83ko1vn+Br/qM7tcMUev/oJuE2pMX3P ce7WzfuWvPNggjI1kjPBK/kql0wu9s/Nm2gIdW+3/cfYvc63Vd8oe8He+m7uFlZKC3OM DqCSmkwaC8bFR++2YlG6w+jq9A4oX/9/UgqQLDnrDRPvrkgsNrdwemK65yh6Oj4Peooz BkymWi18afbp1Y7wB9SRFaEez5oX3rxvVTC1pQx48+txeDE+afMoz/JUIT3kREnSypTj Za/w== X-Gm-Message-State: ALQs6tAwhPgTgePyD4vDyX4PjwYGCLH9SrK+JlwXEpR9nEHJ5rejq3Gs bWzaUl8e4GDtDtEHX2yU7B5GTw== X-Google-Smtp-Source: AIpwx48F7pUHbG27eBq2ylQuoZGBqVYibze5u6/oV7EYRJTHqNg4lJ3Y7LcAJfd22JI++OBFP0JG3w== X-Received: by 10.223.201.12 with SMTP id m12mr3456662wrh.158.1523448488020; Wed, 11 Apr 2018 05:08:08 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:3d14:e3e8:2cef:11e2? (p200300CD6F24EB003D14E3E82CEF11E2.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:3d14:e3e8:2cef:11e2]) by smtp.gmail.com with ESMTPSA id z12sm1232091wrb.29.2018.04.11.05.08.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 05:08:07 -0700 (PDT) To: RTCWeb IETF From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> Date: Wed, 11 Apr 2018 14:08:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 12:08:14 -0000 Hi, there's an ongoing W3C spec discussion regarding the minimum amount of streams that need to be supported by a WebRTC data channel implementation, see: https://github.com/w3c/webrtc-pc/issues/1829 draft-ietf-rtcweb-data-channel-13, section-6.2 states: The number of streams negotiated during SCTP association setup SHOULD be 65535, which is the maximum number of streams that can be negotiated during the association setup. Is there any reason why it needs to be a SHOULD? Could we make this a MUST? Cheers Lennart From nobody Wed Apr 11 11:15:09 2018 Return-Path: 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 74805126CD8 for ; Wed, 11 Apr 2018 11:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2GBOYjMexQO5 for ; Wed, 11 Apr 2018 11:15:06 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB06126C89 for ; Wed, 11 Apr 2018 11:15:06 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id r82so5440827wme.0 for ; Wed, 11 Apr 2018 11:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:references:openpgp:to:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nFR/CWao/t/tQe8+8chska0tJtacjXjJt5k/5fRqNW0=; b=vCoudc7w+7II8XeVh0y+Y5rHTo20PSYZeuXELCUuoV65FzqLY64PNp4eQooCd8sDka 2DY6I2jqOJie8FsEM3/OOY2qoONu8dyqd/9kCeRNCBdTG/aUrDAC6I+jepO8ikPxeEqQ W6irePyno+0W97cLl2rBiwJjtqSN4DLUrXJCO49oLcasJHw78mvka3JRHUwdZFW+ULxV qgdTyRdRzd8qiT4Whi3zzk0Jo3q76GFJiB5ztL+2X2klX+akiR70AWVobx2FJYVvkHgJ wKJ5ekTcIONpLKSh0ahZ0oQLwIjZwbEmXzNChdk2GnuOFfBDkJL5vcg0CB1/TPdPeAKn sWrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:references:openpgp:to:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nFR/CWao/t/tQe8+8chska0tJtacjXjJt5k/5fRqNW0=; b=ThEbESfHOX66CpZ2WquS0Bt2XpMM+KCZcpjred8tOf/dxGvarVxm3M5J/Hwpx65/5E hUc3Wz+U0jucozwyqIxPNy86VIiwIu87/84yRRf7XbzdVCWOJyrCAhzs1UyWsta3s/pA AhS5+kHvAY8K6wHvpE4/t3CMI+Sj53qeFDqvChakBVW00Iofh1/j7HFlLaUisIkJgW/D MR7SYcRvS6P2fn6SN3ebU63AgsCAjoSmLqmfC/UNXAWf+N/tED0eIIJlw7z2YyjvXXr5 UJyxJrBHQdRXxJyRY9Hl1a+WGggZWcA2FUjXdTxHvSEu5GTYa3He95s2CbJb7txa0RtI FhTw== X-Gm-Message-State: ALQs6tBpcsJhTOQcfCWcSbK1byCUWaqPnoNYyOGh5ruhDImiInZL9sCK NlYJJ7OWUJv8vFCdJOM358iPlQ== X-Google-Smtp-Source: AIpwx4/1LjTDKihgEBJzcyWk2nBcDi58bU3mKROz5RiZ2HrtA0AAyIiRwolRL73o8yshBjvNBeopfg== X-Received: by 10.80.166.99 with SMTP id d90mr11049401edc.53.1523470504463; Wed, 11 Apr 2018 11:15:04 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:3d14:e3e8:2cef:11e2? (p200300CD6F24EB003D14E3E82CEF11E2.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:3d14:e3e8:2cef:11e2]) by smtp.gmail.com with ESMTPSA id l1sm1062482edi.54.2018.04.11.11.15.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 11:15:03 -0700 (PDT) From: Lennart Grahl References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> Openpgp: preference=signencrypt To: RTCWeb IETF Message-ID: <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> Date: Wed, 11 Apr 2018 20:15:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 18:15:08 -0000 On 01.04.2018 01:47, Lennart Grahl wrote: > On 01.04.2018 00:26, Justin Uberti wrote: >> As stated before, this is not a problem unique to web browsers. That is, by >> installing a mobile application, you implicitly allow it to use all of your >> network interfaces. As such, trying to design browser mechanisms for >> networking consent seems like misdirected effort. > > First of all, that comparison doesn't really work for me since an app is > much less of a sandbox. So, I personally do not trust arbitrary websites > but I do trust apps that I install (or I just don't install them, or I > partially trust them and revoke some of the permissions they have). > > It's all about expectations: WebRTC networking is special - it does > networking entirely different to what people were accustomed to in > browsers. Which is probably why people are so irritated when they learn > that it leaks IPs even though they've set a proxy or a VPN. And along > with the argument that gUM just does not work for a bunch of use cases, > that is the rationale for my suggestion towards a networking "consent" > mechanism. With that mechanism in place the user has a voice, we cover > more use cases, browsers can ship stricter modes by default without > breaking everything we love about peer-to-peer connections and privacy > extensions might consider dropping WebRTC from their blacklist. I > honestly do not see this as being terribly misguided. Since I haven't seen a satisfactory response so far, let me rephrase this as a question: Can anyone explain to me why that approach is not considered a valid alternative to getUserMedia? Cheers Lennart > >> Perhaps the key issue here is the word 'consent'. If we replaced this with >> some notion of 'trust', i.e., that the user has specifically engaged with >> this app with the intent of having a communications session, maybe that >> provides a way out, as one can easily claim that installed mobile >> applications and web apps with gUM rights are 'trusted'. > > I'm sorry but I don't really see the difference. gUM requests a > permission to access your camera and your microphone and then assumes > you're "trusting" the page for something different as well. > >> >> On Sat, Mar 31, 2018 at 3:18 AM Lennart Grahl >> wrote: >> >>> I really don't have a good suggestion other than being completely >>> honest: "Hey user, I want to establish a direct connection - is that >>> okay for you? Oh, and here is a help page that will tell you what impact >>> this may have on your privacy..." >>> >>> These permission requests don't have to be mutually exclusive either. >>> The above request could also be embedded inside the permission request >>> for getUserMedia to avoid multiple requests: >>> >>> Camera to share: >>> [WebCam 3000 |v] >>> :WebCam 3000 : >>> :WebCam 4000 : >>> >>> Direct connection: (?) <-- "help" button >>> [No (Default) |v] >>> :Yes : >>> :Yes, but hide private addresses : >>> :No (Default) : >>> :No, and force using a proxy : >>> >>> [x] Remember the decision for this page >>> >>> [Don't allow] [Allow] >>> >>> Cheers >>> Lennart >>> >>> On 31.03.2018 00:12, Sean Turner wrote: >>>> >>>> >>>>> On Mar 29, 2018, at 23:48, Lennart Grahl >>> wrote: >>>>> >>>>> I'm fine with the modes, I don't have a strong opinion on whether or not >>>>> an IETF document should include some form of "consent". But I do have a >>>>> problem with the suggestion to use getUserMedia. Can we maybe remove it? >>>> >>>> As the draft shepherd, I’m trying to figure out how to draw this WGLC to >>> a close all in the hopes that we can help each other get this RTCweb WG >>> ship docked. >>>> >>>> As far as dropping the getUserMedia suggestion, I’m a little hesitant to >>> just drop it at this late date. That suggestion has been in the draft >>> since October 2016 and it’s stood the test of a couple of WG reviews; not >>> last calls mind you but there’s been plenty of time for folks to say get >>> that outta there. And technically, it’s just a suggestion with no >>> normative language. So … maybe a happy middle ground is to have another >>> suggestion so that there’s more than one potential mechanism? >>>> >>>> spt >>>> >>> >> From nobody Wed Apr 11 11:50:07 2018 Return-Path: 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 CBE54129502 for ; Wed, 11 Apr 2018 11:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 XQBFeu3wFSYD for ; Wed, 11 Apr 2018 11:50:03 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83BD1250B8 for ; Wed, 11 Apr 2018 11:50:03 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id q38so1838621uad.5 for ; Wed, 11 Apr 2018 11:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PE3So798T5IVV+OKBEgnqpuUy23ud+Et8Br5L+wQ/Ec=; b=SNyAVSpfRF7ynvaM1DcMhO7U5XFiZwMH4TqEXWSZ1DWjne1hxx0t+Z6afYASQoK7e3 7zYqsNP0X+ETv5ObbZOyzOzHnN0QCekDybQa4A2kQZ9D0t9DeKr86kqaOlT3ZwoCKIZ3 VWPC2Q0R32IVT44Wo7f+ffQ4hdb3wLoFcKDnD42EyHlmU2+cwy3dz3kwDrtRkxUuDlvH SVPjiUlcDgeSroBYkRP716rS9nWAc69PwIQ+k753Ht8UtfezR8uSQJoDObbbl8XcYYbl YCC51Gd51kfr4Vc4DaSIDn0Yvvy3+Z2drzbazdtPbAH62pK8RvCVGcCICZaOx9Fa6Pls 6/iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PE3So798T5IVV+OKBEgnqpuUy23ud+Et8Br5L+wQ/Ec=; b=tEBZWtHu81v0lTV2mD5HOvau62dyJVHfldyg3UG+VZ2gctFj3rqedXtGIEQ+eB0y5q A+24ye7rfTaJXH5JaCy1uv62xzcU5LLl7kHHerlaX4x9u78AjDNrqLV9uiythDzzkG9O gn6DJiig5dXXN2twQj4SIFv8TsjOSn+ILduwJAprRoNSmdxCjMsCSIk5cAALh5hkkzMA yTMQP07VBFOJ9ibJqQtCK0+dMt1ZPwPXdunp6Ihg9hz8MCu5UIKJzMgl7bOtRiPpLbH+ mVGCqtGK5nrPMlFXrnXPMbj5b7u3TvkWmSKJep69VZFu4NatvSD8TpxctfyvZ4EZvDsc NXkA== X-Gm-Message-State: ALQs6tCGb/t6qK6o0LRD3/oib8xtH1WOZBjHg5QE55q+Yd87SQNXJ4DN UKhiTESVAa34Es97WhlUPH/djijn58MQOYYF/Y2NbQ== X-Google-Smtp-Source: AIpwx4+IDiuMTkP1WiJEu40ynTWDWiYfgEyuR3CizbJstYvTkhrBIiqJuwtM7QhQiDkvdn7IMkCK0YWEPulcChNLmH8= X-Received: by 10.176.9.223 with SMTP id e31mr4082528uah.175.1523472602376; Wed, 11 Apr 2018 11:50:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Wed, 11 Apr 2018 11:50:01 -0700 (PDT) In-Reply-To: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> From: Taylor Brandstetter Date: Wed, 11 Apr 2018 11:50:01 -0700 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="f403043ede144adbd90569971be9" Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 18:50:06 -0000 --f403043ede144adbd90569971be9 Content-Type: text/plain; charset="UTF-8" The conclusion when this was discussed at IETF 88 was "Set it to maximum and be done with it." Which sounds like MUST to me... On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl wrote: > Hi, > > there's an ongoing W3C spec discussion regarding the minimum amount of > streams that need to be supported by a WebRTC data channel > implementation, see: https://github.com/w3c/webrtc-pc/issues/1829 > > draft-ietf-rtcweb-data-channel-13, section-6.2 states: > > The number of streams negotiated during SCTP association setup SHOULD > be 65535, which is the maximum number of streams that can be > negotiated during the association setup. > > Is there any reason why it needs to be a SHOULD? Could we make this a MUST? > > Cheers > Lennart > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f403043ede144adbd90569971be9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The conclusion when this was discussed at IETF 88 was &quo= t;Set it to maximum and be done with it." Which sounds like MUST to me= ...

On Wed, = Apr 11, 2018 at 5:08 AM, Lennart Grahl <lennart.grahl@gmail.com&= gt; wrote:
Hi,

there's an ongoing W3C spec discussion regarding the minimum amount of<= br> streams that need to be supported by a WebRTC data channel
implementation, see: https://github.com/w3c/webrtc-= pc/issues/1829

draft-ietf-rtcweb-data-channel-13, section-6.2 states:

=C2=A0 =C2=A0The number of streams negotiated during SCTP association setup= SHOULD
=C2=A0 =C2=A0be 65535, which is the maximum number of streams that can be =C2=A0 =C2=A0negotiated during the association setup.

Is there any reason why it needs to be a SHOULD? Could we make this a MUST?=

Cheers
Lennart

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--f403043ede144adbd90569971be9-- From nobody Wed Apr 11 12:11:05 2018 Return-Path: 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 2B39C1271FD for ; Wed, 11 Apr 2018 12:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5P58Y8l3XcR9 for ; Wed, 11 Apr 2018 12:11:02 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87651129C56 for ; Wed, 11 Apr 2018 12:11:02 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id b6-v6so2075983pla.11 for ; Wed, 11 Apr 2018 12:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q8FFGL/rbDYr6jUCNb9Uu/zHL5LyPbeeuJeLy53uGaU=; b=owhSouh0sRnm4lmEG5u9oV0JmUwebRNPZTLNoz7aCVXgR4Ctmg2+TVPqaV7b9BI6Kt OfR8DFia4UTQ8d4H/vLzLQbWNVr2x5tqqwXtk2g5VbAL8X6UiyOp+3NTTYR3Lm8zOV3z 5nBrFo6+hzQgdjeXbw1JOG1juo6HAibQaEapSEJaE8QGxRWK9YxfSh0ergckjEiIDWzp Z6/zXJt2w69YO6+hyn/9mlsfxBJwLOCPE14D1bULRLB40MODgNV7Of48Cq9MJhsMPUGI cy3vdvfUfwLGt+OIHa10rMrATNg7TSTc9C+3XGAOHyv2oGddLQJ94+/8XfyIhPp4nMFP i6LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q8FFGL/rbDYr6jUCNb9Uu/zHL5LyPbeeuJeLy53uGaU=; b=RJRRKJy7kdKWyFQ6wgMnG83wGD2H2MmsoPRvAOxF4F8wtCBqYDMTH9AWN3PANsHJLZ YKsFZZMwj2x1dc4/PMNd6uPFnhntKFxAJ1yupnghmUptTlm7S8CGnXM6DLXh2Sjg1Qiz rTUCfmSxtLddMZn/pI5O3uZZ2IPAOamaaAVY17Jmeh+JPJiD4LCK9Y0VWuSi2XI5CETZ S4Dk8vrZH5XxlXzX8AOMEqRaOwL8c+gR/On6e0WRGjw+LLyzS+PVCbLioeiiwq5CydTu fRyKGk7FmZskR1RMa0xQoZNf7WLlGjcVEpB6fNSL4yOoTGMqYr/Zv+hteTZmSoFpJ1er asfA== X-Gm-Message-State: ALQs6tBtpTISy1GwoR12EX0oW3Eq8voGGf8jYnjmZ2aIuDKILLoBcyzk PH24CMbfQSf9sBIXtBIQKd1FrkVy X-Google-Smtp-Source: AIpwx48hLQRx6xi2oXIcS2YKvjXKR15dIDvqU2SQmtM+c8/8sjtDGkt08UVvew8EJ8hOACetPQjlfw== X-Received: by 2002:a17:902:6709:: with SMTP id f9-v6mr6501556plk.159.1523473861445; Wed, 11 Apr 2018 12:11:01 -0700 (PDT) Received: from [10.221.171.167] (mobile-166-176-186-239.mycingular.net. [166.176.186.239]) by smtp.gmail.com with ESMTPSA id h2sm5157742pfd.119.2018.04.11.12.11.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 12:11:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15E216) In-Reply-To: <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> Date: Wed, 11 Apr 2018 12:10:59 -0700 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <6C355676-7C18-4F6F-970A-59010D6BCA0E@gmail.com> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> To: Lennart Grahl Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 19:11:04 -0000 On Apr 11, 2018, at 11:15 AM, Lennart Grahl wrote:= >=20 > Since I haven't seen a satisfactory response so far, let me rephrase > this as a question: Can anyone explain to me why that approach is not > considered a valid alternative to getUserMedia? [BA] When considering alternative consent models you have to ask if the user= will understand what they are being asked to consent to. For getUserMedia (= or getDisplayMedia) it is relatively clear: access to a device or to the scr= een. But for WebRTC or ORTC, what would you request permission for and when= and how would you explain this to the user? Asking permission for object co= nstruction probably isn=E2=80=99t viable. So would you ask for permission to= create a data channel? To apply a local or remote description? To create a c= ertificate? What if an application created multiple peer connections? How m= any prompts would be required for a 20 person conference?= From nobody Wed Apr 11 12:26:31 2018 Return-Path: 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 54DA51271FD for ; Wed, 11 Apr 2018 12:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 mzmlbdHUWs0T for ; Wed, 11 Apr 2018 12:26:26 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D59D129C6D for ; Wed, 11 Apr 2018 12:26:26 -0700 (PDT) Received: from [IPv6:2003:cd:6f00:5e00:604c:5fd1:fbd6:4e92] (p200300CD6F005E00604C5FD1FBD64E92.dip0.t-ipconnect.de [IPv6:2003:cd:6f00:5e00:604c:5fd1:fbd6:4e92]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id E62BD721E281A; Wed, 11 Apr 2018 21:26:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Michael Tuexen In-Reply-To: Date: Wed, 11 Apr 2018 21:26:20 +0200 Cc: Lennart Grahl , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> To: Taylor Brandstetter X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 19:26:29 -0000 > On 11. Apr 2018, at 20:50, Taylor Brandstetter = wrote: >=20 > The conclusion when this was discussed at IETF 88 was "Set it to = maximum and be done with it." Which sounds like MUST to me.... I think the reason for the SHOULD was that it would allow = implementations with limited resources and knowing that they don't need that number of parallel data channels can = use a lower number. Best regards Michael >=20 > On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl = wrote: > Hi, >=20 > there's an ongoing W3C spec discussion regarding the minimum amount of > streams that need to be supported by a WebRTC data channel > implementation, see: https://github.com/w3c/webrtc-pc/issues/1829 >=20 > draft-ietf-rtcweb-data-channel-13, section-6.2 states: >=20 > The number of streams negotiated during SCTP association setup = SHOULD > be 65535, which is the maximum number of streams that can be > negotiated during the association setup. >=20 > Is there any reason why it needs to be a SHOULD? Could we make this a = MUST? >=20 > Cheers > Lennart >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 11 12:26:43 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB91F129C6D for ; Wed, 11 Apr 2018 12:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523474790; bh=dtKFgOPZoUVb3sB/YsHJgLmRpqZ8hHR6V6JEShLNCwI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=u8MEdtifHqLXuO38Vmv9JuevKQJWZYfo1VLoumXyBzmDNiwHHBJzDaNyOS5cNf6fg I9Nh9cOD7LMzWkMHhqtLTU4zraElGyf5RwWWH83Okuo6qP334+U0U90Vq8XJo9ejU9 4T54WFOPf6bCHrl5mtLfwUtArHO7LOupi0YnoOS4= X-Mailbox-Line: From michael.tuexen@lurchi.franken.de Wed Apr 11 12:26:30 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B9A129C56; Wed, 11 Apr 2018 12:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523474790; bh=dtKFgOPZoUVb3sB/YsHJgLmRpqZ8hHR6V6JEShLNCwI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=u8MEdtifHqLXuO38Vmv9JuevKQJWZYfo1VLoumXyBzmDNiwHHBJzDaNyOS5cNf6fg I9Nh9cOD7LMzWkMHhqtLTU4zraElGyf5RwWWH83Okuo6qP334+U0U90Vq8XJo9ejU9 4T54WFOPf6bCHrl5mtLfwUtArHO7LOupi0YnoOS4= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8731271FD for ; Wed, 11 Apr 2018 12:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 D691jQcdKomg for ; Wed, 11 Apr 2018 12:26:26 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C407129C56 for ; Wed, 11 Apr 2018 12:26:26 -0700 (PDT) Received: from [IPv6:2003:cd:6f00:5e00:604c:5fd1:fbd6:4e92] (p200300CD6F005E00604C5FD1FBD64E92.dip0.t-ipconnect.de [IPv6:2003:cd:6f00:5e00:604c:5fd1:fbd6:4e92]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id E62BD721E281A; Wed, 11 Apr 2018 21:26:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Michael Tuexen In-Reply-To: Date: Wed, 11 Apr 2018 21:26:20 +0200 Cc: Lennart Grahl , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) To: Taylor Brandstetter Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 19:26:31 -0000 > On 11. Apr 2018, at 20:50, Taylor Brandstetter = wrote: >=20 > The conclusion when this was discussed at IETF 88 was "Set it to = maximum and be done with it." Which sounds like MUST to me.... I think the reason for the SHOULD was that it would allow = implementations with limited resources and knowing that they don't need that number of parallel data channels can = use a lower number. Best regards Michael >=20 > On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl = wrote: > Hi, >=20 > there's an ongoing W3C spec discussion regarding the minimum amount of > streams that need to be supported by a WebRTC data channel > implementation, see: https://github.com/w3c/webrtc-pc/issues/1829 >=20 > draft-ietf-rtcweb-data-channel-13, section-6.2 states: >=20 > The number of streams negotiated during SCTP association setup = SHOULD > be 65535, which is the maximum number of streams that can be > negotiated during the association setup. >=20 > Is there any reason why it needs to be a SHOULD? Could we make this a = MUST? >=20 > Cheers > Lennart >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 11 13:10:30 2018 Return-Path: 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 59F4E12D72F for ; Wed, 11 Apr 2018 13:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 VGPllYX0_O3p for ; Wed, 11 Apr 2018 13:10:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C8A1271FD for ; Wed, 11 Apr 2018 13:10:27 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3BKAOLL023683 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Apr 2018 15:10:25 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Lennart Grahl , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> From: Adam Roach Message-ID: <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> Date: Wed, 11 Apr 2018 15:10:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 20:10:29 -0000 [as an individual] On 4/11/18 1:15 PM, Lennart Grahl wrote: > Since I haven't seen a satisfactory response so far, let me rephrase > this as a question: Can anyone explain to me why that approach is not > considered a valid alternative to getUserMedia? I think you're not getting a lot of response here because what you're proposing is well within the bounds of what the current document says. gUM is offered as a non-normative example, but that's all it is. If you believe that document changes are in order, perhaps a concrete proposal along the lines of "change the text to be instead" or "add text at the end of section " would produce more conversation. /a From nobody Wed Apr 11 13:29:26 2018 Return-Path: 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 C680812D72F for ; Wed, 11 Apr 2018 13:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 7qBlGAwpgQId for ; Wed, 11 Apr 2018 13:29:22 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0840D1271FD for ; Wed, 11 Apr 2018 13:29:22 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id n124so1898965vkd.6 for ; Wed, 11 Apr 2018 13:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S+7ti+kDO4I5pn4nBWxMKnFNBHOIWQByq+ZJiqZI+h0=; b=B7Nb5Bt3TW9VD4Tw7GLnzQpdZ7uAZ8DTlnziNpkjbSkxffpMCjHcHN1LqZfQVToA7M 6ww3WUUHHOZekXb+FEfc2E0wPGVWRujLrv6Wb7kz25L40F4/qZFARWGtqpa83EBCY8yA tM2xlT90cKr+BsWW1OJ+j5al6doYjY2QxbEpws+0bstigdyGmEVyODaD71IISSguqmVC 4cjvfJ/gAzU6/yfpuQbYp4ja4cSpbJDLgVtp2UZbCjh1rxA2yojLs2UYR0iIg0T6SILw KnMlnV+tmAKj5rrcAkXyBzh8SXKariiQfnMnx91cIdN2R/eNGlYwZRHDD7bMCSjEq0m2 9SQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S+7ti+kDO4I5pn4nBWxMKnFNBHOIWQByq+ZJiqZI+h0=; b=daC+/RdspirgodrAqTMPBs9PnLEqD+YSDt9vrjLxw7zR9K296FpvMcKX8/C+e1Zt7Q mCWcJOR6NaauXL9BWt6+h8hsreeScIukIK7nLidappjy4D47SNfy8EXkPWZjOGdNyZTZ jDciQ5gmtLALcXEy9PYSnVeDObtBer4GhMWMsFRLeyIU7GkXZCQSPKhI7lflI3WF1TSc 7swxdgvIpfs734fGj/Z2e88+x8BcwhwYNzBwHyydR4nRrU+TuKCWU1U2Y2hUWo9dvczf byqah25V4IwGs+S3nQaM1UnpHuwcCDoTL5NhcT6ZHS6nyIdZYyE09LDoNhfRSbiAcH7Q iSww== X-Gm-Message-State: ALQs6tBu5Qh4KBnbudYboVFoH5tX7U/O54IuDT33423YK77QGlDDk6q6 5o40eOO8z11ro/5EmQU/Kkm6RTdwUG8+UTLomW1hng== X-Google-Smtp-Source: AIpwx4+wvQe/dDBjm4zK2ApTj9k2NLNc6wN4hp26dY/uXgDaXNmcf9V28ORpwpvlKruGVEDGh/guyfGIbkxME2XSDJ4= X-Received: by 10.31.179.66 with SMTP id c63mr4506370vkf.95.1523478560703; Wed, 11 Apr 2018 13:29:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Wed, 11 Apr 2018 13:29:19 -0700 (PDT) In-Reply-To: <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> From: Taylor Brandstetter Date: Wed, 11 Apr 2018 13:29:19 -0700 Message-ID: To: Michael Tuexen Cc: Taylor Brandstetter , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a1143aa466fa06f0569987ee0" Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 20:29:25 -0000 --001a1143aa466fa06f0569987ee0 Content-Type: text/plain; charset="UTF-8" I listened to the recording, and this was the main point being discussed, but the conclusion seemed to be "efficient implementations shouldn't use much (or any) memory for unused streams; we shouldn't make sacrifices in the protocol just to reduce implementation complexity." Discussion starts at 1:42:19: https://www.ietf.org/audio/ietf88/ietf88-regencyd-20131104-1450-pm2.mp3 On Wed, Apr 11, 2018 at 12:26 PM, Michael Tuexen < michael.tuexen@lurchi.franken.de> wrote: > > On 11. Apr 2018, at 20:50, Taylor Brandstetter 40google.com@dmarc.ietf.org> wrote: > > > > The conclusion when this was discussed at IETF 88 was "Set it to maximum > and be done with it." Which sounds like MUST to me.... > I think the reason for the SHOULD was that it would allow implementations > with limited resources and > knowing that they don't need that number of parallel data channels can use > a lower number. > > Best regards > Michael > > > > On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl > wrote: > > Hi, > > > > there's an ongoing W3C spec discussion regarding the minimum amount of > > streams that need to be supported by a WebRTC data channel > > implementation, see: https://github.com/w3c/webrtc-pc/issues/1829 > > > > draft-ietf-rtcweb-data-channel-13, section-6.2 states: > > > > The number of streams negotiated during SCTP association setup SHOULD > > be 65535, which is the maximum number of streams that can be > > negotiated during the association setup. > > > > Is there any reason why it needs to be a SHOULD? Could we make this a > MUST? > > > > Cheers > > Lennart > > > > _______________________________________________ > > 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 > --001a1143aa466fa06f0569987ee0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I listened to the recording, and this was the main point b= eing discussed, but the conclusion seemed to be "efficient implementat= ions shouldn't use much (or any) memory for unused streams; we shouldn&= #39;t make sacrifices in the protocol just to reduce implementation complex= ity."


On Wed= , Apr 11, 2018 at 12:26 PM, Michael Tuexen <michael.tuexen@= lurchi.franken.de> wrote:
&= gt; On 11. Apr 2018, at 20:50, Taylor Brandstetter <deadbeef=3D40google.com@dmarc.ietf.org> wrote:
>
> The conclusion when this was discussed at IETF 88 was "Set it to = maximum and be done with it." Which sounds like MUST to me....
I think the reason for the SHOULD was that it would allow implementations w= ith limited resources and
knowing that they don't need that number of parallel data channels can = use a lower number.

Best regards
Michael
>
> On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl <lennart.grahl@gmail.com> wrote:
> Hi,
>
> there's an ongoing W3C spec discussion regarding the minimum amoun= t of
> streams that need to be supported by a WebRTC data channel
> implementation, see: https://github.com/w3c/webrtc-= pc/issues/1829
>
> draft-ietf-rtcweb-data-channel-13, section-6.2 states:
>
>=C2=A0 =C2=A0 The number of streams negotiated during SCTP association = setup SHOULD
>=C2=A0 =C2=A0 be 65535, which is the maximum number of streams that can= be
>=C2=A0 =C2=A0 negotiated during the association setup.
>
> Is there any reason why it needs to be a SHOULD? Could we make this a = MUST?
>
> Cheers
> Lennart
>
> _______________________________________________
> 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

--001a1143aa466fa06f0569987ee0-- From nobody Wed Apr 11 13:29:39 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 242AE12D77A for ; Wed, 11 Apr 2018 13:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523478566; bh=7FXHqqksL1lv1b5wBGd5/1YEneDYDbAr+hD3MEs+ma8=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=bizZSjJzv4/PB5bNmZX7xLznZ3HFGUXASs28xAA+8+ZFPJ/Ih24JQj3fydKTm+XU4 6Cr7q+PZPZRRL4I6zuvz26I47+WqmAUMr27hJ/d+rw+mhR/PJwDWJKLc6xn3h65ck0 f4R4U28wpJI+nTptQNDgkZA+8Jf/KcQT4fga2q7M= X-Mailbox-Line: From deadbeef@google.com Wed Apr 11 13:29:25 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0A612AF84; Wed, 11 Apr 2018 13:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523478565; bh=7FXHqqksL1lv1b5wBGd5/1YEneDYDbAr+hD3MEs+ma8=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=b20qObPlwhjYVW9KQTYbolaw38pF/3PSCbUftnRZU2NrIPD2t0pU9H/1rY+CjAIq8 2lrJy092nGlW+CtWajB5WmgUzIDxzx8xUGd9oFsh87exRvbWTAu8e+ZcTJDOUqwJgi yywhgBg9K+fzFW1I1Sc1vt7dlJSMUrFTX8tPGRH0= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972231271FD for ; Wed, 11 Apr 2018 13:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 uRDIo0ExZgyN for ; Wed, 11 Apr 2018 13:29:22 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EDE812AF84 for ; Wed, 11 Apr 2018 13:29:22 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id v205so1893428vkv.13 for ; Wed, 11 Apr 2018 13:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S+7ti+kDO4I5pn4nBWxMKnFNBHOIWQByq+ZJiqZI+h0=; b=B7Nb5Bt3TW9VD4Tw7GLnzQpdZ7uAZ8DTlnziNpkjbSkxffpMCjHcHN1LqZfQVToA7M 6ww3WUUHHOZekXb+FEfc2E0wPGVWRujLrv6Wb7kz25L40F4/qZFARWGtqpa83EBCY8yA tM2xlT90cKr+BsWW1OJ+j5al6doYjY2QxbEpws+0bstigdyGmEVyODaD71IISSguqmVC 4cjvfJ/gAzU6/yfpuQbYp4ja4cSpbJDLgVtp2UZbCjh1rxA2yojLs2UYR0iIg0T6SILw KnMlnV+tmAKj5rrcAkXyBzh8SXKariiQfnMnx91cIdN2R/eNGlYwZRHDD7bMCSjEq0m2 9SQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S+7ti+kDO4I5pn4nBWxMKnFNBHOIWQByq+ZJiqZI+h0=; b=dyU8f0+ugGjq9iHJjeb0rREK2JC96enzKDvZFVxfUFfSDt9rROTBv9KR5BQDJbJZK8 NZe2lGlyX3jA+vZlKRUuZq9NKxBt2N5hT45P4qScMKKzUeBk6JehpmaThLUHjvJVHV/V ZqHtKVmJUiOsG9XD1U0/243CvLMDZkKnRWHrZ2xOiuD8AWQ9RoPomr221rXWQ5dmbGO4 AFneBmgsjU5fAYK7NX643ywrOHqEhJk0uMi2lhZv7aGBdoZ93L84MJwqvoKHKXuz56Fp dFv/8wPetZtImbDXnlNgv5c6eAw8PG3dyuoqLncvXtA1++sxjbM7EsnbLISt+AnrA0lA LDow== X-Gm-Message-State: ALQs6tBde3mpalAS/EeojBpCjs4WYYsgWxcZP98N2JY4vRdrtZgYY7GT mrZ80+OLP4rzMN0s6mGKzGxZC9QFOlhtF55k1TsyVQ== X-Google-Smtp-Source: AIpwx4+wvQe/dDBjm4zK2ApTj9k2NLNc6wN4hp26dY/uXgDaXNmcf9V28ORpwpvlKruGVEDGh/guyfGIbkxME2XSDJ4= X-Received: by 10.31.179.66 with SMTP id c63mr4506370vkf.95.1523478560703; Wed, 11 Apr 2018 13:29:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Wed, 11 Apr 2018 13:29:19 -0700 (PDT) In-Reply-To: <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> From: Taylor Brandstetter Date: Wed, 11 Apr 2018 13:29:19 -0700 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary="001a1143aa466fa06f0569987ee0" Cc: Taylor Brandstetter Cc: RTCWeb IETF Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 20:29:26 -0000 --001a1143aa466fa06f0569987ee0 Content-Type: text/plain; charset="UTF-8" I listened to the recording, and this was the main point being discussed, but the conclusion seemed to be "efficient implementations shouldn't use much (or any) memory for unused streams; we shouldn't make sacrifices in the protocol just to reduce implementation complexity." Discussion starts at 1:42:19: https://www.ietf.org/audio/ietf88/ietf88-regencyd-20131104-1450-pm2.mp3 On Wed, Apr 11, 2018 at 12:26 PM, Michael Tuexen < michael.tuexen@lurchi.franken.de> wrote: > > On 11. Apr 2018, at 20:50, Taylor Brandstetter 40google.com@dmarc.ietf.org> wrote: > > > > The conclusion when this was discussed at IETF 88 was "Set it to maximum > and be done with it." Which sounds like MUST to me.... > I think the reason for the SHOULD was that it would allow implementations > with limited resources and > knowing that they don't need that number of parallel data channels can use > a lower number. > > Best regards > Michael > > > > On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl > wrote: > > Hi, > > > > there's an ongoing W3C spec discussion regarding the minimum amount of > > streams that need to be supported by a WebRTC data channel > > implementation, see: https://github.com/w3c/webrtc-pc/issues/1829 > > > > draft-ietf-rtcweb-data-channel-13, section-6.2 states: > > > > The number of streams negotiated during SCTP association setup SHOULD > > be 65535, which is the maximum number of streams that can be > > negotiated during the association setup. > > > > Is there any reason why it needs to be a SHOULD? Could we make this a > MUST? > > > > Cheers > > Lennart > > > > _______________________________________________ > > 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 > --001a1143aa466fa06f0569987ee0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I listened to the recording, and this was the main point b= eing discussed, but the conclusion seemed to be "efficient implementat= ions shouldn't use much (or any) memory for unused streams; we shouldn&= #39;t make sacrifices in the protocol just to reduce implementation complex= ity."


On Wed= , Apr 11, 2018 at 12:26 PM, Michael Tuexen <michael.tuexen@= lurchi.franken.de> wrote:
&= gt; On 11. Apr 2018, at 20:50, Taylor Brandstetter <deadbeef=3D40google.com@dmarc.ietf.org> wrote:
>
> The conclusion when this was discussed at IETF 88 was "Set it to = maximum and be done with it." Which sounds like MUST to me....
I think the reason for the SHOULD was that it would allow implementations w= ith limited resources and
knowing that they don't need that number of parallel data channels can = use a lower number.

Best regards
Michael
>
> On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl <lennart.grahl@gmail.com> wrote:
> Hi,
>
> there's an ongoing W3C spec discussion regarding the minimum amoun= t of
> streams that need to be supported by a WebRTC data channel
> implementation, see: https://github.com/w3c/webrtc-= pc/issues/1829
>
> draft-ietf-rtcweb-data-channel-13, section-6.2 states:
>
>=C2=A0 =C2=A0 The number of streams negotiated during SCTP association = setup SHOULD
>=C2=A0 =C2=A0 be 65535, which is the maximum number of streams that can= be
>=C2=A0 =C2=A0 negotiated during the association setup.
>
> Is there any reason why it needs to be a SHOULD? Could we make this a = MUST?
>
> Cheers
> Lennart
>
> _______________________________________________
> 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

--001a1143aa466fa06f0569987ee0-- From nobody Wed Apr 11 14:24:48 2018 Return-Path: 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 CD0D112EBE6 for ; Wed, 11 Apr 2018 14:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 gN3aLepmmUdz for ; Wed, 11 Apr 2018 14:24:43 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0552612EAAF for ; Wed, 11 Apr 2018 14:24:18 -0700 (PDT) Received: from [IPv6:2003:cd:6f00:5e00:604c:5fd1:fbd6:4e92] (p200300CD6F005E00604C5FD1FBD64E92.dip0.t-ipconnect.de [IPv6:2003:cd:6f00:5e00:604c:5fd1:fbd6:4e92]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id EBEA0721E281A; Wed, 11 Apr 2018 23:24:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Michael Tuexen In-Reply-To: Date: Wed, 11 Apr 2018 23:24:13 +0200 Cc: Taylor Brandstetter , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <1683BDE2-6E74-40BD-966B-ED7DFEB58083@lurchi.franken.de> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> To: Taylor Brandstetter X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 21:24:47 -0000 > On 11. Apr 2018, at 22:29, Taylor Brandstetter = wrote: >=20 > I listened to the recording, and this was the main point being = discussed, but the conclusion seemed to be "efficient implementations = shouldn't use much (or any) memory for unused streams; we shouldn't make = sacrifices in the protocol just to reduce implementation complexity." You can implement it in a way to not use much memory for unused streams. = However, you need some memory for stream you use. That is why I referred to the number of streams used = in parallel. Another point to be considered is that currently most implementations = don't offer 65665 incoming streams. So if you would change it to a MUST, not many implementations would be = compliant. If you change it to a MUST, I would expect that implementations ABORT = the SCTP association when the peer violates the specification by not requesting 65535 outgoing = streams and allowing 65535 incoming streams. So what do you gain by changing to from SHOULD to MUST? Best regards Michael >=20 > Discussion starts at 1:42:19: = https://www.ietf.org/audio/ietf88/ietf88-regencyd-20131104-1450-pm2.mp3 >=20 > On Wed, Apr 11, 2018 at 12:26 PM, Michael Tuexen = wrote: > > On 11. Apr 2018, at 20:50, Taylor Brandstetter = wrote: > > > > The conclusion when this was discussed at IETF 88 was "Set it to = maximum and be done with it." Which sounds like MUST to me.... > I think the reason for the SHOULD was that it would allow = implementations with limited resources and > knowing that they don't need that number of parallel data channels can = use a lower number. >=20 > Best regards > Michael > > > > On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl = wrote: > > Hi, > > > > there's an ongoing W3C spec discussion regarding the minimum amount = of > > streams that need to be supported by a WebRTC data channel > > implementation, see: https://github.com/w3c/webrtc-pc/issues/1829 > > > > draft-ietf-rtcweb-data-channel-13, section-6.2 states: > > > > The number of streams negotiated during SCTP association setup = SHOULD > > be 65535, which is the maximum number of streams that can be > > negotiated during the association setup. > > > > Is there any reason why it needs to be a SHOULD? Could we make this = a MUST? > > > > Cheers > > Lennart > > > > _______________________________________________ > > 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Wed Apr 11 14:25:04 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C874B12DA29 for ; Wed, 11 Apr 2018 14:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523481887; bh=+DoMuyXqK3CUT/CwK5s7Fgky9WYpHiJ/wS4o/bmPOEI=; h=Subject:From:In-Reply-To:Date:References:To:Cc:Cc; b=Dn3vHX2J2MzARor5yuxF16mIrbN4lOhgEwaPXiswa+Tc7HYk01M6FnmrJnuvXrlil 5lq2Xv4yCV3Q0cx4kb2yEiR9EdB973YnSnnnhrnE3x7HYkRQ9BF4+8HhUhrAgWzhrA KsBDs+NYPf7y+l5Z+dIcnQNEi5or7/kWFauJWNAo= X-Mailbox-Line: From michael.tuexen@lurchi.franken.de Wed Apr 11 14:24:46 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F347112D887; Wed, 11 Apr 2018 14:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523481886; bh=+DoMuyXqK3CUT/CwK5s7Fgky9WYpHiJ/wS4o/bmPOEI=; h=Subject:From:In-Reply-To:Date:References:To:Cc:Cc; b=UJZDkVa1r6nN7jKXxtLxYe5/KfN4sKi+IT8Nthmd9F0amaTJO9fnJRkqwUmL7ZewE XOyuXgyxRhWdjSBOK0F9SQO2+CZk7PWFgDeNRY9qqruMpAahiVJ4/kOP6WTHys3uvB xJDhIACkICa8Yxi7NIW5hhK4TPd3cf4iMPzVzhVc= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB95712DA13 for ; Wed, 11 Apr 2018 14:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 izxCLpd6_Vdg for ; Wed, 11 Apr 2018 14:24:41 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922BB12EA9F for ; Wed, 11 Apr 2018 14:24:18 -0700 (PDT) Received: from [IPv6:2003:cd:6f00:5e00:604c:5fd1:fbd6:4e92] (p200300CD6F005E00604C5FD1FBD64E92.dip0.t-ipconnect.de [IPv6:2003:cd:6f00:5e00:604c:5fd1:fbd6:4e92]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id EBEA0721E281A; Wed, 11 Apr 2018 23:24:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Michael Tuexen In-Reply-To: Date: Wed, 11 Apr 2018 23:24:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1683BDE2-6E74-40BD-966B-ED7DFEB58083@lurchi.franken.de> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> To: Taylor Brandstetter X-Mailer: Apple Mail (2.3445.6.18) Cc: Taylor Brandstetter Cc: RTCWeb IETF Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 21:24:49 -0000 > On 11. Apr 2018, at 22:29, Taylor Brandstetter = wrote: >=20 > I listened to the recording, and this was the main point being = discussed, but the conclusion seemed to be "efficient implementations = shouldn't use much (or any) memory for unused streams; we shouldn't make = sacrifices in the protocol just to reduce implementation complexity." You can implement it in a way to not use much memory for unused streams. = However, you need some memory for stream you use. That is why I referred to the number of streams used = in parallel. Another point to be considered is that currently most implementations = don't offer 65665 incoming streams. So if you would change it to a MUST, not many implementations would be = compliant. If you change it to a MUST, I would expect that implementations ABORT = the SCTP association when the peer violates the specification by not requesting 65535 outgoing = streams and allowing 65535 incoming streams. So what do you gain by changing to from SHOULD to MUST? Best regards Michael >=20 > Discussion starts at 1:42:19: = https://www.ietf.org/audio/ietf88/ietf88-regencyd-20131104-1450-pm2.mp3 >=20 > On Wed, Apr 11, 2018 at 12:26 PM, Michael Tuexen = wrote: > > On 11. Apr 2018, at 20:50, Taylor Brandstetter = wrote: > > > > The conclusion when this was discussed at IETF 88 was "Set it to = maximum and be done with it." Which sounds like MUST to me.... > I think the reason for the SHOULD was that it would allow = implementations with limited resources and > knowing that they don't need that number of parallel data channels can = use a lower number. >=20 > Best regards > Michael > > > > On Wed, Apr 11, 2018 at 5:08 AM, Lennart Grahl = wrote: > > Hi, > > > > there's an ongoing W3C spec discussion regarding the minimum amount = of > > streams that need to be supported by a WebRTC data channel > > implementation, see: https://github.com/w3c/webrtc-pc/issues/1829 > > > > draft-ietf-rtcweb-data-channel-13, section-6.2 states: > > > > The number of streams negotiated during SCTP association setup = SHOULD > > be 65535, which is the maximum number of streams that can be > > negotiated during the association setup. > > > > Is there any reason why it needs to be a SHOULD? Could we make this = a MUST? > > > > Cheers > > Lennart > > > > _______________________________________________ > > 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Wed Apr 11 15:31:13 2018 Return-Path: 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 849541277BB for ; Wed, 11 Apr 2018 15:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 N3y2mOrxIJEL for ; Wed, 11 Apr 2018 15:31:09 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7880E126BF7 for ; Wed, 11 Apr 2018 15:31:09 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id 132so3859058qkd.5 for ; Wed, 11 Apr 2018 15:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=viUGSheNS0AOQMEVroz+WrMKa7aK7+0DvQIcyiBN1no=; b=QEzXcsUl6DG3578qY4tUqd/A4yRBtE5c7cUPIHJzbC/J2vEPwb4PgRHhHyd3olUpqY 4zF4q7fN08jyeYXGsUsNmM0w9SlPifSeSvChwAS1DarAK2ZZ4UTEkEVTqjHKY+ceRgAd gEK5SRaWZpAwikOTX4ScucRGTZcZJ/iOr7ULs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=viUGSheNS0AOQMEVroz+WrMKa7aK7+0DvQIcyiBN1no=; b=jBnj/ieTr6imBngN144dVKtG+LPmAkTI6WQn1jDckFw8olkb4ps4gL+3K1FMAg/bpM 8c8A9vnzWUBNLbNRmL832MIYobsIz/CaoFH12c20y7dx6jeRZBqxlp5pHUZELKJHq6mK TY75/2W2mYPyaamy64K5rqNjOMpY8Xiatp2uttftA+U6hmkYXWcMvkgOv2MZdLly9AzT F5boltWAJVxRNQXgKyRS/BCwf96pGPKqhRm+42t0hbq5osotP08CnQijHr2vlg/Waghz pblaExM6OoJhZQyDFXNAcGnY6AF7lBO/asbGh0jpL3sBXk7I1q8O/ZFzDFWmw2aZRHCp mkmQ== X-Gm-Message-State: ALQs6tDFsrQSOCpH/2IjHmEcDZvSu7s4Mtf8mXZX8DGpAAkLLZ05lHPu tqt+FsQqlHgrgKN8RW9VKiXll05DHws= X-Google-Smtp-Source: AIpwx49hi2OdS8QZmo3QM+X1e20uLRmKsOR7Ztl1FGdeftvoMFBWgqN2AP2e6hvSXhMOewpTNMo0Qg== X-Received: by 10.55.25.196 with SMTP id 65mr3902809qkz.64.1523485868409; Wed, 11 Apr 2018 15:31:08 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id 1sm1846854qtr.85.2018.04.11.15.31.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 15:31:07 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 11 Apr 2018 18:31:06 -0400 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> To: RTCWeb IETF In-Reply-To: <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> Message-Id: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 22:31:11 -0000 > On Apr 11, 2018, at 16:10, Adam Roach wrote: >=20 > [as an individual] >=20 > On 4/11/18 1:15 PM, Lennart Grahl wrote: >> Since I haven't seen a satisfactory response so far, let me rephrase >> this as a question: Can anyone explain to me why that approach is not >> considered a valid alternative to getUserMedia? >=20 >=20 > I think you're not getting a lot of response here because what you're = proposing is well within the bounds of what the current document says. = gUM is offered as a non-normative example, but that's all it is. If you = believe that document changes are in order, perhaps a concrete proposal = along the lines of "change the text to be instead" or "add text = at the end of section " would produce more conversation. As the draft=E2=80=99s Shepherd trying to figure out how to bring = closure on this issue, I like to offer a summary: There=E2=80=99s some discomfort with the use of the term =E2=80=9Cuser = consent=E2=80=9D as well as the non-normative example provided for how = to get it. The problem with changing the term to something else is "user = consent" is a term of art; we can=E2=80=99t really qualify it with = something like =E2=80=9Cinformed=E2=80=9D, because we=E2=80=99d need to = explain what that means (and well GDPR =E2=80=A6), and; frankly the term = is used extensively in the other security draft that we pruned = ip-handling from. The problem with changing the non-normative example = is that there don=E2=80=99t seem to be other attractive/realistic = alternatives. What I=E2=80=99d like to do is remind everybody that we pruned this = draft from the other security drafts to allow it to be updated faster = because it=E2=80=99s about a much narrower subject. With this in mind = and Bernard=E2=80=99s long list of questions, I would like to propose = that we:* 1) Add another sentence (from Tim) that indicates there are other = alternatives: Alternatively implementations can provide a separate mechanism to obtain user consent. 2) Progress the draft out of the WG.* 3) Update/Obsolete this draft, when a much superior alternative emerges. spt * Also "hold your nose" if you=E2=80=99re sad about this proposal but = are willing to begrudgingly live with the rough consensus; it=E2=80=99s = rough and we noted this in the Shepherd write-up. ** Remember that during the IETF LC we (or somebody in the wider IETF = community) might come up with something during the IETF LC.= From nobody Wed Apr 11 16:00:01 2018 Return-Path: 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 C82AE12D7EC for ; Wed, 11 Apr 2018 15:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 AgBZzeXetPwK for ; Wed, 11 Apr 2018 15:59:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0301277BB for ; Wed, 11 Apr 2018 15:59:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1467ABE38; Wed, 11 Apr 2018 23:59:53 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoI84lTBg4px; Wed, 11 Apr 2018 23:59:52 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C55F1BE2E; Wed, 11 Apr 2018 23:59:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1523487592; bh=efxlo26PRKg47Wx1a915LpxCCRl2mIuA23MiPPIaMbA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=tLoYmD1eH/TSV8ww3zFJg7m5eMfqia8tKvYWPHd17+sCIAIvP4EyJCpAuYihIJ5ut k/ejbETH3RtmO4/tAef740HhuLI84FfHmEMagGX4HmRWbFmL9kr7pKx6NdaA+0lQwF mfC1obdqBJWeIrohRL2wk0lIvRI+K/qjwnhN2FuA= To: Sean Turner , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <9451870b-b216-aca8-c7ef-6453d6276d0a@cs.tcd.ie> Date: Wed, 11 Apr 2018 23:59:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s23RKMrpJ8MopYW07HS0u9hUzkBw3kUbz" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 22:59:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s23RKMrpJ8MopYW07HS0u9hUzkBw3kUbz Content-Type: multipart/mixed; boundary="y3OeEIWD9w1juGM560Gb0FytJsCgDTpVu"; protected-headers="v1" From: Stephen Farrell To: Sean Turner , RTCWeb IETF Message-ID: <9451870b-b216-aca8-c7ef-6453d6276d0a@cs.tcd.ie> Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> In-Reply-To: --y3OeEIWD9w1juGM560Gb0FytJsCgDTpVu Content-Type: multipart/mixed; boundary="------------09F0B28E47CB267C2C3598D7" Content-Language: en-GB This is a multi-part message in MIME format. --------------09F0B28E47CB267C2C3598D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/04/18 23:31, Sean Turner wrote: > * Also "hold your nose" if you=E2=80=99re sad about this proposal but a= re > willing to begrudgingly live with the rough consensus; it=E2=80=99s rou= gh and > we noted this in the Shepherd write-up. Yep. (I could argue as to whether "consent" in the web is a term of art or is really a term worthy of the artful dodger, but that's not in scope here:-) I think it might be worthwhile recording in the shepherd write-up that the "consent" term caused a chunk of the controversy - that's not quite a "privacy issue" per-se. S. --------------09F0B28E47CB267C2C3598D7 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------09F0B28E47CB267C2C3598D7-- --y3OeEIWD9w1juGM560Gb0FytJsCgDTpVu-- --s23RKMrpJ8MopYW07HS0u9hUzkBw3kUbz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJazpNnAAoJEFqy+vF7FyvqjOQQALUxWdUJ7lzDa2654Dgm/+io 9zY2UwtZfmsY/PJc2qxP1BWZjp+uNl9sEFgH5Lvpk00/wcYthgMUE2qihP8Al/pi A6jHpiGPfcaMyCZ6P2Z/wD9gegOfVAHGwzi7ISZjJrtRh4YraK9dc5pPwO5hyuJU ImrlYoph9LudlKtdmcJiUojmFc+eqC8qe6YuwXrIlVrUoJvuEPAOs92tGeFgiktM 2ZFBNVh1b2WKzgq+//uAeFPy7TMoj98IpATu/Vp+QGWviY/vVBFyrd3l7X5phXUo pA8pEaTKjc4aBAtp0Na2Rh7rnaG0Bl+3H6iFCGTh2272vH8LYCe2Zf5q4W/kwjAA XCmlNlNzRRMzQrCqb8wWB8GktPybQvFmhi9+XLDUCIbCuMY3GkK8ckUKniRhSVpp tUeMLCY+IIhy9RCBLE90Oy2SNwfNuhVc/QMwJ9TgFrmHJ0s/j3EGqZIdjRWp6vHa GR92lbifAIoUIAC1j+2yvhISiKLvfGgZnP49minGs5ooqZOIA9tRszUdJJeXzrBN Fk2u1twSBQYumfIhOQcz5wZceMLI/M7x5U8jYszeuX3Lg/1nWLwI8MZyZgWnESyE ehGZHJ3anMWQb9Q0hdC6Jw0GaX+hxy3LJ9al0zhwcvz9K92Edail6EFt1rv9uXyE ugQ42JJvd2fLq+4UW5XN =+wBv -----END PGP SIGNATURE----- --s23RKMrpJ8MopYW07HS0u9hUzkBw3kUbz-- From nobody Wed Apr 11 16:48:03 2018 Return-Path: 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 3CBD812D7F8 for ; Wed, 11 Apr 2018 16:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ch8FHAZ0BgBh for ; Wed, 11 Apr 2018 16:47:59 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883561201F2 for ; Wed, 11 Apr 2018 16:47:59 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id x204so2177468vkd.7 for ; Wed, 11 Apr 2018 16:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7pjtHR2enH9v6OTYbYH4PKQnYKhmwVs1gSXArSa4jjI=; b=AcuHIJdUwpqjTbctNzKZC98fK/PEN0moJ6JtjmGpGwDcz1YVSEslrX8P8UODin4whS XJhT0PIXP0zUDAYL31vH0DeDTSq0gzTAf1cvxAXrKlnaKaz52lqOVoOXqOUq6ywzWpd4 hEkwzWgEVsSCG2zVctrj7IDIP6CkIX3F9eH6A4bzwCrp4IYMNpWhPLFSUPFywlUligzk JKrm/rsSUXm0b2y7hwVBPHSIV6KOjOwvbGA3h7X8sIGbT1MV33PSyvwfa6CTuFteEefY 23y2A7ZoZLz5w2vK4D3Bj/A4jBkr74ftvLS43DDskf8s9RDdhnHAf0WUlFqryGvDxR24 5TGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7pjtHR2enH9v6OTYbYH4PKQnYKhmwVs1gSXArSa4jjI=; b=lPpmLlOObLXetYsFtbQjtg6WQCq2mBvOPfGfzNR4UQ+oyY2Ng6t9JpkfjZzuK7bTIL JnXvClghXopr8hYhWSvXHC052fEgY8Txje86RMkWoS4dzC+R2XmhXhuJsyZsmYejPZdm k9V/50FfUQ418Uy5XxC0x8djcLj87B6+ltVtpL5bLVed/NIRlA2gwLWaI6hElGR05LPn NTmVUu2x2OkU7AOBec85B/w1NNSkCTFlBcaaw00mWZa3iINVaOq1BF0HV1+08t4nTbsM PLyzLUneELGzfi6Oi/xCoux+r3cP+GDmuBfhD0/yxmwYrsThQbjBvCHVd1XIALZsp0u3 BNQw== X-Gm-Message-State: ALQs6tCBjEFS+tFvTRyBDcQgni8ujKozE6giA77l6g2mIEIVh1r2eK7Y ImPigC2I3GuEspepbiGnhnW3A6tuvqcB+d82CdgDWcis X-Google-Smtp-Source: AIpwx48sH3l1/ohbSvr1KK92YOc00+ut5XvOvHdMSlI+rOZBre5cKZYRxuVgMnNXf+M2rCFoyFeSINKqCt08CAPqb/I= X-Received: by 10.31.228.5 with SMTP id b5mr5202823vkh.120.1523490478199; Wed, 11 Apr 2018 16:47:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.100 with HTTP; Wed, 11 Apr 2018 16:47:37 -0700 (PDT) In-Reply-To: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> From: Bernard Aboba Date: Wed, 11 Apr 2018 16:47:37 -0700 Message-ID: To: Sean Turner Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c09198ec599b705699b44d8" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 23:48:02 -0000 --94eb2c09198ec599b705699b44d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sean said: "1) Add another sentence (from Tim) that indicates there are other alternatives: Alternatively implementations can provide a separate mechanism to obtain user consent. 2) Progress the draft out of the WG.* 3) Update/Obsolete this draft, when a much superior alternative emerges." [BA] This seems like the best we can do at the moment. With respect to alternatives, they have been explored and will no doubt continue to be. But it's not clear (at least to me) what metrics can be used to determine whether an implemented alternative is "superior". On Wed, Apr 11, 2018 at 3:31 PM, Sean Turner wrote: > > > > On Apr 11, 2018, at 16:10, Adam Roach wrote: > > > > [as an individual] > > > > On 4/11/18 1:15 PM, Lennart Grahl wrote: > >> Since I haven't seen a satisfactory response so far, let me rephrase > >> this as a question: Can anyone explain to me why that approach is not > >> considered a valid alternative to getUserMedia? > > > > > > I think you're not getting a lot of response here because what you're > proposing is well within the bounds of what the current document says. gU= M > is offered as a non-normative example, but that's all it is. If you belie= ve > that document changes are in order, perhaps a concrete proposal along the > lines of "change the text to be instead" or "add text at the > end of section " would produce more conversation. > > As the draft=E2=80=99s Shepherd trying to figure out how to bring closure= on this > issue, I like to offer a summary: > > There=E2=80=99s some discomfort with the use of the term =E2=80=9Cuser co= nsent=E2=80=9D as well as > the non-normative example provided for how to get it. The problem with > changing the term to something else is "user consent" is a term of art; w= e > can=E2=80=99t really qualify it with something like =E2=80=9Cinformed=E2= =80=9D, because we=E2=80=99d need > to explain what that means (and well GDPR =E2=80=A6), and; frankly the te= rm is used > extensively in the other security draft that we pruned ip-handling from. > The problem with changing the non-normative example is that there don=E2= =80=99t > seem to be other attractive/realistic alternatives. > > What I=E2=80=99d like to do is remind everybody that we pruned this draft= from the > other security drafts to allow it to be updated faster because it=E2=80= =99s about a > much narrower subject. With this in mind and Bernard=E2=80=99s long list= of > questions, I would like to propose that we:* > > 1) Add another sentence (from Tim) that indicates there are other > alternatives: > > Alternatively implementations can provide a separate > mechanism to obtain user consent. > > 2) Progress the draft out of the WG.* > > 3) Update/Obsolete this draft, when a much superior alternative emerges. > > spt > > * Also "hold your nose" if you=E2=80=99re sad about this proposal but are= willing > to begrudgingly live with the rough consensus; it=E2=80=99s rough and we = noted this > in the Shepherd write-up. > > ** Remember that during the IETF LC we (or somebody in the wider IETF > community) might come up with something during the IETF LC. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c09198ec599b705699b44d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sean said:=C2=A0

"1) Add another sentence (from Tim) that indicates there are othe= r alternatives:

=C2=A0 =C2=A0 =C2=A0 Alterna= tively implementations can provide a separate
=C2=A0 =C2=A0 =C2=A0 mechanism to obtain user consent.

2) Progress the draft out of the WG.*

3) Update/Obsolete this draft, when a much superior alternative = emerges."

[BA] This seems like the best we can do at= the moment.=C2=A0=C2=A0

With respect to alternatives, th= ey have been explored and will no doubt continue to be.=C2=A0
<= div>
But it's not clear= (at least to me) what metrics can be used to determine whether an implemen= ted alternative is "superior".=C2=A0






On Wed, Apr 11, 2018 at 3:31 PM, = Sean Turner <sean@sn3rd.com> wrote:


> On Apr 11, 2018, at 16:10, Adam Roach <adam@nostrum.com> wrote:
>
> [as an individual]
>
> On 4/11/18 1:15 PM, Lennart Grahl wrote:
>> Since I haven't seen a satisfactory response so far, let me re= phrase
>> this as a question: Can anyone explain to me why that approach is = not
>> considered a valid alternative to getUserMedia?
>
>
> I think you're not getting a lot of response here because what you= 're proposing is well within the bounds of what the current document sa= ys. gUM is offered as a non-normative example, but that's all it is. If= you believe that document changes are in order, perhaps a concrete proposa= l along the lines of "change the text <x> to be <y> instea= d" or "add text <z> at the end of section <q>" w= ould produce more conversation.

As the draft=E2=80=99s Shepherd trying to figure out how to bring cl= osure on this issue, I like to offer a summary:

There=E2=80=99s some discomfort with the use of the term =E2=80=9Cuser cons= ent=E2=80=9D as well as the non-normative example provided for how to get i= t. The problem with changing the term to something else is "user conse= nt" is a term of art; we can=E2=80=99t really qualify it with somethin= g like =E2=80=9Cinformed=E2=80=9D, because we=E2=80=99d need to explain wha= t that means (and well GDPR =E2=80=A6), and; frankly the term is used exten= sively in the other security draft that we pruned ip-handling from.=C2=A0 T= he problem with changing the non-normative example is that there don=E2=80= =99t seem to be other attractive/realistic alternatives.

What I=E2=80=99d like to do is remind everybody that we pruned this draft f= rom the other security drafts to allow it to be updated faster because it= =E2=80=99s about a much narrower subject.=C2=A0 With this in mind and Berna= rd=E2=80=99s long list of questions, I would like to propose that we:*

1) Add another sentence (from Tim) that indicates there are other alternati= ves:

=C2=A0 =C2=A0 =C2=A0 Alternatively implementations can provide a separate =C2=A0 =C2=A0 =C2=A0 mechanism to obtain user consent.

2) Progress the draft out of the WG.*

3) Update/Obsolete this draft, when a much superior alternative emerges.
spt

* Also "hold your nose" if you=E2=80=99re sad about this proposal= but are willing to begrudgingly live with the rough consensus; it=E2=80=99= s rough and we noted this in the Shepherd write-up.

** Remember that during the IETF LC we (or somebody in the wider IETF commu= nity) might come up with something during the IETF LC.
______________________________= _________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--94eb2c09198ec599b705699b44d8-- From nobody Wed Apr 11 20:03:08 2018 Return-Path: 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 08ED0127599 for ; Wed, 11 Apr 2018 20:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 EuSLumJCZE_v for ; Wed, 11 Apr 2018 20:03:05 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1CA12D945 for ; Wed, 11 Apr 2018 20:03:05 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id b198so4504333qkg.9 for ; Wed, 11 Apr 2018 20:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3wZXqZXfdhPIjK7cycG8TPl2czyEHHi0YEevywjJoyE=; b=P5aJTV4fJWSzKwwq8D3K8FlMmI8MIpxUcdL7ztI4PISPCURRqQ9O6quh4HtzCzDjF2 V76SSM712mw/4Gcp67p1Cl1cSS+4ukrE3aSK16YF/WV/MEaWyUq+BvH1yDr6GWSpWNCj nOe2WFTDEASPt9csul6kJ21bTs75Ssk4uSFmw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3wZXqZXfdhPIjK7cycG8TPl2czyEHHi0YEevywjJoyE=; b=auKo0bdNgu2Uoo1hkZfWr3Zhm0xtvhy2Eh9CaSQtm2PAudM2HusLOVekeLDfXYKLkg UxytKatfaZ66XK8l8BAbHtNkC3X3uCjvD5sQhmYSuywOZroysLwi1aUxcpMbtX/P48EP VWMqpGCoWQnE1Q0KASS6yXV6qNRWWDNwm4tKV7g1amH68m2me0zuuE9KbAdaTpLWfRDl aafWIBdHcQ+Y2o8I2pEKFDkyHdoeQLfSOj+Cz/q3mkz5Q7mgvpTuoocofAeqF9u2YBjH 73EO+2Q9lP+kk1s2R7Gitmi9HEIJt+quGbX3HkZH8wnXtdFya+aTW6nxBpgJ47w5qFE+ +NVg== X-Gm-Message-State: ALQs6tAQG4RDU7sh7spk3VoTemaO9u54STcHskAbOrs1apZ2+QdZLvIH C7DglSYnu5hvkOcPW0mtv5XTFb/KW74= X-Google-Smtp-Source: AIpwx48kZqh/5dC9gPZtWSH7hVDdsncipKPbXC5yLNxOG3Z8vMEsNJg04LlIBWX4mydQMchnAsD7qQ== X-Received: by 10.55.172.9 with SMTP id e9mr10783139qkm.112.1523502184051; Wed, 11 Apr 2018 20:03:04 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id b201sm1921254qkg.48.2018.04.11.20.03.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 20:03:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <9451870b-b216-aca8-c7ef-6453d6276d0a@cs.tcd.ie> Date: Wed, 11 Apr 2018 23:03:01 -0400 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <9451870b-b216-aca8-c7ef-6453d6276d0a@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 03:03:07 -0000 > On Apr 11, 2018, at 18:59, Stephen Farrell = wrote: >=20 >=20 >=20 > On 11/04/18 23:31, Sean Turner wrote: >> * Also "hold your nose" if you=E2=80=99re sad about this proposal but = are >> willing to begrudgingly live with the rough consensus; it=E2=80=99s = rough and >> we noted this in the Shepherd write-up. > Yep. >=20 > (I could argue as to whether "consent" in the web is a term of art or > is really a term worthy of the artful dodger, but that's not in scope > here:-) >=20 > I think it might be worthwhile recording in the shepherd write-up that > the "consent" term caused a chunk of the controversy - that's not = quite > a "privacy issue" per-se. >=20 > S. Fair point. spt From nobody Thu Apr 12 05:22:27 2018 Return-Path: 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 75252120724 for ; Thu, 12 Apr 2018 05:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BxjdjcU_JT5e for ; Thu, 12 Apr 2018 05:22:24 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE93A126C26 for ; Thu, 12 Apr 2018 05:22:23 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id i3so9221216wmf.3 for ; Thu, 12 Apr 2018 05:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1/UntP2iV4zM2NNwT4e8ycxOWf/sibwoTV/ldptWrcA=; b=AMgP6FsMOnwacEzXAufiqc3we8OK2yptlJROe2jcvexeF79CuyHmNflk20DWuDwxzN SCwtwskReInPHT8z+lIeWDo03SO1bIUghvICtA21RbSiDhA2fb61hihkHKn0LcYZzv/0 uRVdJQpezjiTZ22aCClcKwQ9y9DBE0qT4HgVWqaoIGhOzNXsLnr/jC1/FBitsw16OeFF NxGUWRQsF/VSG4R/ymtf5c4e5q9ZVYlNDsqlJ4zoUcd4gn1peD6S+h3vviSMUL0xKfHJ Ojzj7GaWBBhO8Puu6B7yZ/GtSvBRaXYJEV/w/0m0HfGPLJ0eDwrPb0Jf74GCfo2qJ/WI zYKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1/UntP2iV4zM2NNwT4e8ycxOWf/sibwoTV/ldptWrcA=; b=th+YB8AFakbadSqyqJ0VU7h9oCdNdGKw4hS3pueh+xZBOA7r7ruWgoHWLWeMCzp0xB lXeRJqQ55jcMG1gFEXDX0j+eHQHrxOAikf0qpMSTSRr5NO/WM8x94DjOdtI7Db8+OjfH +HRs2CjVSiUtY75zrPKSTphzGSv34YSJK52PVQqP/r3nIHpGVjEPE8V9jiZHOk2qaXSr 3B2cRflCvnX/XR6f7WK6pLEmrtMx/KmdYg+wXtdz6I3FB7ujKgnix46LLuHO/+Xj23Sp m3nxmm2XVEd1c67pnBtmgOA83Fs4+icmrOSKJOEIM8dlLA8hivXZSWo0DjVUuq3Vsd9U IqjQ== X-Gm-Message-State: ALQs6tDcIPA4JZ+TTy50UNuXwmwkd0hCqPiq6ephFmWa60Qyz7cfGkNE MmFrV82VoHuUdLIITcUNHjR+xg== X-Google-Smtp-Source: AIpwx4+kPof0i4/RwVgVKQcLHYFDStewQ/0yEz2Nur7k4ZrHcPZFxQQyFvng/hSaKOZEEmUI4/NdxQ== X-Received: by 10.80.173.196 with SMTP id b4mr15381215edd.168.1523535741909; Thu, 12 Apr 2018 05:22:21 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:5cda:3e20:eb99:6efc? (p200300CD6F24EB005CDA3E20EB996EFC.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:5cda:3e20:eb99:6efc]) by smtp.gmail.com with ESMTPSA id n8sm1925243edi.69.2018.04.12.05.22.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 05:22:21 -0700 (PDT) To: rtcweb@ietf.org References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: Date: Thu, 12 Apr 2018 14:22:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 12:22:25 -0000 On 12.04.2018 00:31, Sean Turner wrote: >> On Apr 11, 2018, at 16:10, Adam Roach wrote: >> >> [as an individual] >> >> On 4/11/18 1:15 PM, Lennart Grahl wrote: >>> Since I haven't seen a satisfactory response so far, let me rephrase >>> this as a question: Can anyone explain to me why that approach is not >>> considered a valid alternative to getUserMedia? >> >> >> I think you're not getting a lot of response here because what you're proposing is well within the bounds of what the current document says. gUM is offered as a non-normative example, but that's all it is. If you believe that document changes are in order, perhaps a concrete proposal along the lines of "change the text to be instead" or "add text at the end of section " would produce more conversation. Thanks, this and the response from Bernard is good feedback that I should provide a more concrete proposal next time. > As the draft’s Shepherd trying to figure out how to bring closure on this issue, I like to offer a summary: > > There’s some discomfort with the use of the term “user consent” as well as the non-normative example provided for how to get it. The problem with changing the term to something else is "user consent" is a term of art; we can’t really qualify it with something like “informed”, because we’d need to explain what that means (and well GDPR …), and; frankly the term is used extensively in the other security draft that we pruned ip-handling from. The problem with changing the non-normative example is that there don’t seem to be other attractive/realistic alternatives. > > What I’d like to do is remind everybody that we pruned this draft from the other security drafts to allow it to be updated faster because it’s about a much narrower subject. With this in mind and Bernard’s long list of questions, I would like to propose that we:* > > 1) Add another sentence (from Tim) that indicates there are other alternatives: > > Alternatively implementations can provide a separate > mechanism to obtain user consent. > > 2) Progress the draft out of the WG.* > > 3) Update/Obsolete this draft, when a much superior alternative emerges. > > spt > > * Also "hold your nose" if you’re sad about this proposal but are willing to begrudgingly live with the rough consensus; it’s rough and we noted this in the Shepherd write-up. > > ** Remember that during the IETF LC we (or somebody in the wider IETF community) might come up with something during the IETF LC. I realise I've joined a tad late and it should be clear by now that I have a strong reluctance when it comes to using getUserMedia for the purpose of getting consent to use mode 1. But you are correct, it is non-normative and I'm more irritated by the implementations that don't provide an alternative than this document. Still, I would appreciate if the sentence from Tim you mentioned in 1) will be added. Regarding 3): Like Bernard, I'm unsure how to determine a "superior alternative" (especially in the context of a non-normative section). Cheers Lennart From nobody Thu Apr 12 05:42:07 2018 Return-Path: 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 B314E126FB3 for ; Thu, 12 Apr 2018 05:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 ahkl9aerjnRg for ; Thu, 12 Apr 2018 05:42:02 -0700 (PDT) Received: from smtpcmd04131.aruba.it (smtpcmd04131.aruba.it [62.149.158.131]) by ietfa.amsl.com (Postfix) with ESMTP id D2077126C26 for ; Thu, 12 Apr 2018 05:42:01 -0700 (PDT) Received: from lminiero ([93.44.66.252]) by smtpcmd04.ad.aruba.it with bizsmtp id ZQhz1x00Q5SZVm501QhzeE; Thu, 12 Apr 2018 14:42:00 +0200 Date: Thu, 12 Apr 2018 14:41:58 +0200 From: Lorenzo Miniero To: Lennart Grahl Cc: rtcweb@ietf.org Message-ID: <20180412144158.44733ac7@lminiero> In-Reply-To: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1523536920; bh=JH8/ycDOz0WKtvNYLKKFCl41hAcMvtxhxzM71V7KvbY=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=grE8996gaYO6akppUjQRTMbu6Lst/7yLp9S2SwuOOXgQ7hzoR01vp0JIrP1J4qEB0 FbT7HDv1voC6sltNBDNQrBL4XhUWwzJKyNkvCZ24Savp7U6QVAJzKMVTlnrFtE35+c nZj3NBWC6IV84kgx4J8b7tHwx3DogFouXLP82EXjPeX8YgoScnKT4hxm16vHvs6BqU WAsDCVZz/205MdNTKAnhRU6/0SFIvLEMPYeBrp9EXlSr5oo51/DOVUQebKK+/PMFxY eQyqInp9UDISub584449hI+AXqGxRI+ue10dS6P55K3xiE35MTa2TZxvq3VeMhM1Vi juMjCL0+uejyQ== Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 12:42:06 -0000 On Thu, 12 Apr 2018 14:22:17 +0200 Lennart Grahl wrote: > On 12.04.2018 00:31, Sean Turner wrote: > >> On Apr 11, 2018, at 16:10, Adam Roach wrote: > >> > >> [as an individual] > >> > >> On 4/11/18 1:15 PM, Lennart Grahl wrote: =20 > >>> Since I haven't seen a satisfactory response so far, let me > >>> rephrase this as a question: Can anyone explain to me why that > >>> approach is not considered a valid alternative to getUserMedia? =20 > >> > >> > >> I think you're not getting a lot of response here because what > >> you're proposing is well within the bounds of what the current > >> document says. gUM is offered as a non-normative example, but > >> that's all it is. If you believe that document changes are in > >> order, perhaps a concrete proposal along the lines of "change the > >> text to be instead" or "add text at the end of section > >> " would produce more conversation. =20 >=20 > Thanks, this and the response from Bernard is good feedback that I > should provide a more concrete proposal next time. >=20 > > As the draft=E2=80=99s Shepherd trying to figure out how to bring closu= re > > on this issue, I like to offer a summary: > >=20 > > There=E2=80=99s some discomfort with the use of the term =E2=80=9Cuser = consent=E2=80=9D as > > well as the non-normative example provided for how to get it. The > > problem with changing the term to something else is "user consent" > > is a term of art; we can=E2=80=99t really qualify it with something like > > =E2=80=9Cinformed=E2=80=9D, because we=E2=80=99d need to explain what t= hat means (and well > > GDPR =E2=80=A6), and; frankly the term is used extensively in the other > > security draft that we pruned ip-handling from. The problem with > > changing the non-normative example is that there don=E2=80=99t seem to = be > > other attractive/realistic alternatives. > >=20 > > What I=E2=80=99d like to do is remind everybody that we pruned this dra= ft > > from the other security drafts to allow it to be updated faster > > because it=E2=80=99s about a much narrower subject. With this in mind = and > > Bernard=E2=80=99s long list of questions, I would like to propose that = we:* > >=20 > > 1) Add another sentence (from Tim) that indicates there are other > > alternatives: > >=20 > > Alternatively implementations can provide a separate > > mechanism to obtain user consent. > >=20 > > 2) Progress the draft out of the WG.* > >=20 > > 3) Update/Obsolete this draft, when a much superior alternative > > emerges. > >=20 > > spt > >=20 > > * Also "hold your nose" if you=E2=80=99re sad about this proposal but a= re > > willing to begrudgingly live with the rough consensus; it=E2=80=99s rou= gh > > and we noted this in the Shepherd write-up. > >=20 > > ** Remember that during the IETF LC we (or somebody in the wider > > IETF community) might come up with something during the IETF LC. =20 >=20 > I realise I've joined a tad late and it should be clear by now that I > have a strong reluctance when it comes to using getUserMedia for the > purpose of getting consent to use mode 1. But you are correct, it is > non-normative and I'm more irritated by the implementations that don't > provide an alternative than this document. Still, I would appreciate > if the sentence from Tim you mentioned in 1) will be added. >=20 > Regarding 3): Like Bernard, I'm unsure how to determine a "superior > alternative" (especially in the context of a non-normative section). >=20 Since there seems to be a call for proposed text: The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. It should be noted, though, that getUserMedia consent is typically only required when users are supposed to share media content from their local devices. This may not always be the case, e.g., in scenarios where users will only be receiving media (e.g., a broadcast), or when PeerConnections are created for the sole purpose of setting up datachannels. Requiring getUserMedia consent when it's not really needed may end up discouraging users from establishing a media session, or getting unwarranted access to more information they meant to share. As such, alternative and more appropriate means for getting user consent for Mode 1 are suggested. Probably overly verbose, but it voices my (and I think Lennart's) concern with the current text. Lorenzo --=20 I'm getting older but, unlike whisky, I'm not getting any better https://twitter.com/elminiero From nobody Thu Apr 12 05:53:06 2018 Return-Path: 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 5A2D112704A for ; Thu, 12 Apr 2018 05:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 1Pz_ObqxD7It for ; Thu, 12 Apr 2018 05:53:02 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95901126579 for ; Thu, 12 Apr 2018 05:53:02 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id s78so5836955qkl.8 for ; Thu, 12 Apr 2018 05:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fhfe7aRJfqCm/O6kYQGxnONVK90WlNPTffoz6ZeKk5g=; b=ktXo/jn9nULQiT2cJAUyBUYyWbcnUrB3FFa9EHpIagWTXnZrntIEeJPCKNgrgV3tz+ ZmeOcIYtKw32NNKGkBiYSkxQUqiGrFdFtmLKVtru02mhPEd/dJ3bOGaMfaXj0EuVdjqC vYwcXFleY1nPg1YRGWQFrLm4xYFQBHHQa4gsY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fhfe7aRJfqCm/O6kYQGxnONVK90WlNPTffoz6ZeKk5g=; b=juRsy5T/e8tvywQyTGwK1BAEQO9Vb0/mnB2/v+LcercjXtZp2X2/ZAsGn9T8lUgpqc iEext4UwrhUrMD4pM+wel2K3XnS+ukQkeRYe52LNcDAUYx+18+BKFq/GacuvPGihTyXJ l8cih6TwFLz/ApIxfPeFVmOmLwhgRr/uQCUDmELI1L9Q+lG7zK4+sy0Dr8ySzZcb2Wlb 8UcGxuKZG9KLndh9exJnoanwU9vJ/UsTy6aw4I20QdybnjPolNJJm9VJs0RxZJQgY3Zq ET15G2CqE1ztSRwB67n9MhnN5BEEnT5AaEM/cgZblB9ybEfaBrEN5dZjMPoJ2EDOktta D7Nw== X-Gm-Message-State: ALQs6tBDOEvcpEfUTQH2O0Z9ZxzRn9dskQ7Xr5ZljsupdHDznHioMdM8 +RDSJbOYNqwbu7wLNFSoM43asA== X-Google-Smtp-Source: AIpwx49vjdzrAEHXOkQKA9/OMws+JIuhtLm1N9UTHfGil42YXf8StLEe8mqwq/SQyllCsKdBZ8iO7w== X-Received: by 10.55.214.7 with SMTP id t7mr943008qki.341.1523537581610; Thu, 12 Apr 2018 05:53:01 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id a20sm2723790qkb.17.2018.04.12.05.53.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 05:53:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: Date: Thu, 12 Apr 2018 08:52:59 -0400 Cc: rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5F3FF735-83FE-4B07-BBC7-02311D6DFB81@sn3rd.com> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> To: Lennart Grahl X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 12:53:05 -0000 > On Apr 12, 2018, at 08:22, Lennart Grahl = wrote: >=20 > On 12.04.2018 00:31, Sean Turner wrote: >>> On Apr 11, 2018, at 16:10, Adam Roach wrote: >>>=20 >>> [as an individual] >>>=20 >>> On 4/11/18 1:15 PM, Lennart Grahl wrote: >>>> Since I haven't seen a satisfactory response so far, let me = rephrase >>>> this as a question: Can anyone explain to me why that approach is = not >>>> considered a valid alternative to getUserMedia? >>>=20 >>>=20 >>> I think you're not getting a lot of response here because what = you're proposing is well within the bounds of what the current document = says. gUM is offered as a non-normative example, but that's all it is. = If you believe that document changes are in order, perhaps a concrete = proposal along the lines of "change the text to be instead" or = "add text at the end of section " would produce more = conversation. >=20 > Thanks, this and the response from Bernard is good feedback that I > should provide a more concrete proposal next time. >=20 >> As the draft=E2=80=99s Shepherd trying to figure out how to bring = closure on this issue, I like to offer a summary: >>=20 >> There=E2=80=99s some discomfort with the use of the term =E2=80=9Cuser = consent=E2=80=9D as well as the non-normative example provided for how = to get it. The problem with changing the term to something else is "user = consent" is a term of art; we can=E2=80=99t really qualify it with = something like =E2=80=9Cinformed=E2=80=9D, because we=E2=80=99d need to = explain what that means (and well GDPR =E2=80=A6), and; frankly the term = is used extensively in the other security draft that we pruned = ip-handling from. The problem with changing the non-normative example = is that there don=E2=80=99t seem to be other attractive/realistic = alternatives. >>=20 >> What I=E2=80=99d like to do is remind everybody that we pruned this = draft from the other security drafts to allow it to be updated faster = because it=E2=80=99s about a much narrower subject. With this in mind = and Bernard=E2=80=99s long list of questions, I would like to propose = that we:* >>=20 >> 1) Add another sentence (from Tim) that indicates there are other = alternatives: >>=20 >> Alternatively implementations can provide a separate >> mechanism to obtain user consent. >>=20 >> 2) Progress the draft out of the WG.* >>=20 >> 3) Update/Obsolete this draft, when a much superior alternative = emerges. >>=20 >> spt >>=20 >> * Also "hold your nose" if you=E2=80=99re sad about this proposal but = are willing to begrudgingly live with the rough consensus; it=E2=80=99s = rough and we noted this in the Shepherd write-up. >>=20 >> ** Remember that during the IETF LC we (or somebody in the wider IETF = community) might come up with something during the IETF LC. >=20 > I realise I've joined a tad late and it should be clear by now that I > have a strong reluctance when it comes to using getUserMedia for the > purpose of getting consent to use mode 1. But you are correct, it is > non-normative and I'm more irritated by the implementations that don't > provide an alternative than this document. Still, I would appreciate = if > the sentence from Tim you mentioned in 1) will be added. I already submitted a PR :) https://github.com/juberti/draughts/pull/98 > Regarding 3): Like Bernard, I'm unsure how to determine a "superior > alternative" (especially in the context of a non-normative section). >=20 > Cheers > Lennart >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 12 06:45:25 2018 Return-Path: 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 D66411273E2 for ; Thu, 12 Apr 2018 06:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 lLQIFqfBHpAe for ; Thu, 12 Apr 2018 06:45:21 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F78124BE8 for ; Thu, 12 Apr 2018 06:45:21 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id h4so6188136qtn.13 for ; Thu, 12 Apr 2018 06:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=0HjOai1x6SZ1SvPfu2RViYvw2iREwC4eJY/NnTw/ZZ4=; b=EE84M6eYwDBMWcgm1RY2Omf0XOTDCpHiILAH4XJAvt+6zxV/GaNs9do19kRRj2Zbmm 5wuGyM90KdGpfyVYjjZiEc0J7+D9NKKvvVvMXTFsVQRaXs55Mmtvgh5uhT+zOWZL38TB AeFuzE/tB+mH3uiU4U8gftiUu60w+Z3xfsapc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=0HjOai1x6SZ1SvPfu2RViYvw2iREwC4eJY/NnTw/ZZ4=; b=uDQyQ01Buo3bAC8VA5DNtega4UHlcfh+Jm6exsZwkUIjfbNiKkv8k8s+tzeN6vuly3 6U/NSOBwrzHd8rOVfv0lCN0fNyixcgJejWZyxTtE/dx5YD5w/T9XJExos7D88l1W3EPR xu/O5E5URstHtH3ow27FPgWAdNrDbmCBrIgtkuqhzvmntCNZ2juk5hqZnZe6dIzmy2II thxlAEwBQVR3nDD3/eIZMuI673CAFKjpmTyuEIzhp9S2+ZE3n8zXZ+oV12LKCDVQn6PY GfnFeaLisZGVoXrD/Dy5FU0UCqj3G3yhaC0sPdfKIwnzDVFDIZiwpCazBV0YeDdjlUOP OhAQ== X-Gm-Message-State: ALQs6tAklr2C7Y9PJ+iH+6O3X5j37WllBQClKSjf9cKW7yLbQnDjEC5u KZwbl1b59fXwBmjXz8R7PqmH9UYXE8s= X-Google-Smtp-Source: AIpwx49Z1yXwI4+6Hoj4iIS9oachzy9B0TO9aCoRLUdCflHEBjLKzidwBBjwP0QsH8RjupqZACUd4g== X-Received: by 10.237.37.202 with SMTP id y10mr1370432qtc.62.1523540720395; Thu, 12 Apr 2018 06:45:20 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id c137sm2867181qkb.2.2018.04.12.06.45.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 06:45:19 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 12 Apr 2018 09:45:18 -0400 References: To: RTCWeb IETF In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 13:45:24 -0000 The WGLC for this document has ended. I think it was really good that @ = IETF101 the IdP hackathon happened because it looked like they might = have uncovered something to be changed in our document and possibly in = the webrtc-pc draft; see the [0] thread. As the Shepherd trying to = drive this to closure, we need to we need to decide what changes might = be made in draft-ietf-rtcweb-security-arch. In that thread, I saw two = things that we might change (both from mt): 0) More text to address a linkability concern: As a practical matter, if the browser were to use the same certificate for multiple origins, then it would create a massive privacy problem that enables linkability (aka user tracking). I couldn't find that written down, but I thought it was. If it isn't written down, then we should correct that. I actually think this is basically covered here: https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.1 But want to make sure others agree: 1) Tweak protocol to include an identifier to prevent reuse of assertion = on every RTCPeerConnection: More complex sites frequently generate multiple RTCPeerConnection instances for their communications, especially for group conversations. If the browser requests an assertion once and they use that value for every RTCPeerConnection, then that's OK. =46rom my perspective, I would be happy modifying the protocol to include an identifier and prevent that; for this the IdP can use caching or its local storage. So, what would that look like? Did I miss anything else that needs to be addressed? spt [0] = https://mailarchive.ietf.org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7jXEw > On Mar 12, 2018, at 19:08, Sean Turner wrote: >=20 > All, >=20 > This is the WGLC for the =E2=80=9CWebRTC Security Architecture=E2=80=9D = draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. Please = review the draft and send your comments to this list by 2359UTC on April = 6th, 2018. >=20 > Note the gh repo is here: > https://github.com/rtcweb-wg/security-arch >=20 > Thanks, > C/T/S From nobody Thu Apr 12 16:22:09 2018 Return-Path: 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 6C11C124D6C for ; Thu, 12 Apr 2018 16:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wR_83mbfM7NG for ; Thu, 12 Apr 2018 16:22:06 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D42F12422F for ; Thu, 12 Apr 2018 16:22:06 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y7so6604420wrh.10 for ; Thu, 12 Apr 2018 16:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Gc+uZ278nyO6FvL1Obq1aPO2Oz2n5Mlp6POiZYBGokY=; b=BtNxjlkOT/Zk/UC39ysytxzhPPIWq649rvE7dCQyq3k4F/KdG59uKUzm1N4U5XBIeW IpeKjjpMxMRj3RuCoMynHzOwG15hS6TNE8wJItMTO8cdGsRc0CKbvr6EGUvw7/Ub9HeS HV8+7K4S5qBH+/uFSzoZ8T/99R68ub21e+THp0cbffZj9KaUxoriyVb0vQES0DDzhAhp QIshw9HU3L2Tue5DiWvJXgwK2RWDk0yd0phaN8Ad9SRrEzjibw5WtCIINiV70UmlotYL uhBejkcFzwX49PmZCpZNhsN5sWyRKXQJlpAkD/MSfTRvUe5kGWe0o0ZlvO4tfkRULWlH esVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:cc:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Gc+uZ278nyO6FvL1Obq1aPO2Oz2n5Mlp6POiZYBGokY=; b=BfoCMN16GyfcPOyVYGYZXBwZIi6oyRy8t8cVPpNTbv2FXlxRZQtMYkccOmvB8NajeO htBgvKBj52GDgvK4l2jyr01ka2uLNiwVKLd34Z+3HFxPDg/4H8fU1ycFVQZU17B550fa Q8CLujj2oo7qPTyl1LQTq87ryr8nO3dEmwUnkIV584Lqdj3oQULaM1IPqIh/qeC63C35 Hya8pzB9yfPhBjUBqqJ0+UZgINHNh37X1Qj1GyMNvi4Q0ojEJJMZkeBtOcptskoB6zBg Nqix+C/51ccCNekj4AnKTHGhUBNyMya0bDaq24S1iXGJAzmDoXOAz6aw88AC/uw2uwSc wpuA== X-Gm-Message-State: ALQs6tAy1HIn5CACoeWlYggXt8D10T7vpFVJL005uA2Cq0awJRuoz+jM qcEtvVhfaOW9mOxPsxWaOFU= X-Google-Smtp-Source: AIpwx48G9lNuqDX5t8+mL1rPqEVd82zI9Wmzl3RhhDANMX0b0AeLC3Ulal6a6OPD3ze28Ph8J0ee8Q== X-Received: by 10.223.134.213 with SMTP id 21mr1907587wry.221.1523575324801; Thu, 12 Apr 2018 16:22:04 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:5cda:3e20:eb99:6efc? (p200300CD6F24EB005CDA3E20EB996EFC.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:5cda:3e20:eb99:6efc]) by smtp.gmail.com with ESMTPSA id k28sm7725734wrk.96.2018.04.12.16.22.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 16:22:04 -0700 (PDT) To: rtcweb@ietf.org References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> <1683BDE2-6E74-40BD-966B-ED7DFEB58083@lurchi.franken.de> From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: <2302437f-68b9-b68f-ac14-011f4cf4066d@gmail.com> Date: Fri, 13 Apr 2018 01:22:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1683BDE2-6E74-40BD-966B-ED7DFEB58083@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 23:22:08 -0000 On 11.04.2018 23:24, Michael Tuexen wrote: >> On 11. Apr 2018, at 22:29, Taylor Brandstetter wrote: >> >> I listened to the recording, and this was the main point being discussed, but the conclusion seemed to be "efficient implementations shouldn't use much (or any) memory for unused streams; we shouldn't make sacrifices in the protocol just to reduce implementation complexity." > You can implement it in a way to not use much memory for unused streams. However, you need some memory > for stream you use. That is why I referred to the number of streams used in parallel. So, implementations with limited resources may still choose to negotiate less than that to prevent running into exhausting their resources. That makes sense to me, so I would withdraw the request to make it a MUST. Could this explanation be added as a comment to the draft, so it's clear why it's not a MUST? FWIW, I don't believe any browser would count as an implementation with limited resources. But I get that there are other implementations outside of the browser and it may make sense there to limit the amount of streams. And since we can interoperate with them, we need to handle it some way or another in the W3C WebRTC spec. Taylor, any objections? Cheers Lennart From nobody Thu Apr 12 16:49:06 2018 Return-Path: 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 8B848124D6C for ; Thu, 12 Apr 2018 16:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TISnreijoe99 for ; Thu, 12 Apr 2018 16:49:02 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78E5126CBF for ; Thu, 12 Apr 2018 16:49:01 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id r191so1609561wmg.4 for ; Thu, 12 Apr 2018 16:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yS9097yX07I6d3G4/5U4QViKTjAp63i4Ecq4+wlOq9A=; b=IDJidsMUbZa3M/xo+uFpYy0VPkdVOp8vpiLUXWH+fw4iQE85unXHh3u0a5zpkRzqUo iJS53iv0uJNcIbYHuDeOyAAdDF5PXBx/NQN0ZPIgYRYRFO/pb8+mBMhkHqyEzoTV+jSt C/gw/0qiKYHqj4KLcv0+EMpAiDVB5EBErHlgIXmTJknZG7QK+C/X9CE2AWdAxaW8n1tb bpLDTbj8TMiZ6erI++1rsEn6mCQMvde0HIN2xkEamFA+a0DZtDQjSJhbcCTfWomQPcjn eq5w0OI96RA72DQYp1r3RsZRqaKHEb4H7B9esWBz9cwWdCMQfYvMPIV5F+SlGFUjDxrE szSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yS9097yX07I6d3G4/5U4QViKTjAp63i4Ecq4+wlOq9A=; b=jz664Vr9QBQYRSY3RS4gvSqkRcWHTKEftjQDxQX24XU7m6bQN/VXnszQ+k58zFLSn7 ncZ4iWsiDPWpimXksEGFwuHVylKOZq6IDw3f1S+POSyIzCjUr3iZvBisFtVMrn4Jm1Dz mMBpxRcxq57Vtt/JiUf49tOOvhn8xOMWCedGdXwfJ5VkzHdv/TDjeAqTHcnKby1BuITY mtUmVKmgGb1Ljabp9hUEUyzN+yiuEOQNAXo24MQ4rj26leNZifAf5f7zj07gATuhN2Lv tzvQs0ylVQDqkdV9RphoEbYnMcX3KYDPeGen7lH7UTV1/qapFiJE5bcpKK95P9PFjSy1 QgtQ== X-Gm-Message-State: ALQs6tBWWOhlb882cRvH2yKIyqfBdL0amHkc5aMbRsE20AxpGJ4b3CTk mj0tZBGLTrZjr9Izzs96ahVC5BiE X-Google-Smtp-Source: AIpwx48penfFhVJj1q+ECnRDaay83js5aRGWz+/TBuxD5+3/YjxxLjT1dBTCbNSbOSZMiirO1hKTpg== X-Received: by 10.80.170.152 with SMTP id q24mr18198226edc.43.1523576940148; Thu, 12 Apr 2018 16:49:00 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:5cda:3e20:eb99:6efc? (p200300CD6F24EB005CDA3E20EB996EFC.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:5cda:3e20:eb99:6efc]) by smtp.gmail.com with ESMTPSA id s8sm2615040edk.76.2018.04.12.16.48.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 16:48:59 -0700 (PDT) To: Lorenzo Miniero Cc: rtcweb@ietf.org References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: Date: Fri, 13 Apr 2018 01:48:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180412144158.44733ac7@lminiero> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 23:49:04 -0000 On 12.04.2018 14:41, Lorenzo Miniero wrote: > On Thu, 12 Apr 2018 14:22:17 +0200 > Lennart Grahl wrote: > >> On 12.04.2018 00:31, Sean Turner wrote: >>>> On Apr 11, 2018, at 16:10, Adam Roach wrote: >>>> >>>> [as an individual] >>>> >>>> On 4/11/18 1:15 PM, Lennart Grahl wrote: >>>>> Since I haven't seen a satisfactory response so far, let me >>>>> rephrase this as a question: Can anyone explain to me why that >>>>> approach is not considered a valid alternative to getUserMedia? >>>> >>>> >>>> I think you're not getting a lot of response here because what >>>> you're proposing is well within the bounds of what the current >>>> document says. gUM is offered as a non-normative example, but >>>> that's all it is. If you believe that document changes are in >>>> order, perhaps a concrete proposal along the lines of "change the >>>> text to be instead" or "add text at the end of section >>>> " would produce more conversation. >> >> Thanks, this and the response from Bernard is good feedback that I >> should provide a more concrete proposal next time. >> >>> As the draft’s Shepherd trying to figure out how to bring closure >>> on this issue, I like to offer a summary: >>> >>> There’s some discomfort with the use of the term “user consent” as >>> well as the non-normative example provided for how to get it. The >>> problem with changing the term to something else is "user consent" >>> is a term of art; we can’t really qualify it with something like >>> “informed”, because we’d need to explain what that means (and well >>> GDPR …), and; frankly the term is used extensively in the other >>> security draft that we pruned ip-handling from. The problem with >>> changing the non-normative example is that there don’t seem to be >>> other attractive/realistic alternatives. >>> >>> What I’d like to do is remind everybody that we pruned this draft >>> from the other security drafts to allow it to be updated faster >>> because it’s about a much narrower subject. With this in mind and >>> Bernard’s long list of questions, I would like to propose that we:* >>> >>> 1) Add another sentence (from Tim) that indicates there are other >>> alternatives: >>> >>> Alternatively implementations can provide a separate >>> mechanism to obtain user consent. >>> >>> 2) Progress the draft out of the WG.* >>> >>> 3) Update/Obsolete this draft, when a much superior alternative >>> emerges. >>> >>> spt >>> >>> * Also "hold your nose" if you’re sad about this proposal but are >>> willing to begrudgingly live with the rough consensus; it’s rough >>> and we noted this in the Shepherd write-up. >>> >>> ** Remember that during the IETF LC we (or somebody in the wider >>> IETF community) might come up with something during the IETF LC. >> >> I realise I've joined a tad late and it should be clear by now that I >> have a strong reluctance when it comes to using getUserMedia for the >> purpose of getting consent to use mode 1. But you are correct, it is >> non-normative and I'm more irritated by the implementations that don't >> provide an alternative than this document. Still, I would appreciate >> if the sentence from Tim you mentioned in 1) will be added. >> >> Regarding 3): Like Bernard, I'm unsure how to determine a "superior >> alternative" (especially in the context of a non-normative section). >> > > > Since there seems to be a call for proposed text: > > The details of this consent are left to the implementation; one > potential mechanism is to tie this consent to getUserMedia > consent. It should be noted, though, that getUserMedia > consent is typically only required when users are supposed to > share media content from their local devices. This may not > always be the case, e.g., in scenarios where users will only > be receiving media (e.g., a broadcast), or when > PeerConnections are created for the sole purpose of setting up > datachannels. Requiring getUserMedia consent when it's not > really needed may end up discouraging users from establishing > a media session, or getting unwarranted access to more > information they meant to share. As such, alternative and more > appropriate means for getting user consent for Mode 1 are > suggested. > > Probably overly verbose, but it voices my (and I think Lennart's) > concern with the current text. Likely a verbose version of https://github.com/juberti/draughts/pull/98. But I appreciate and would agree with that since it clarifies that some non-obvious use cases exists that we have found throughout the years where getUserMedia is painful (if anything). I don't know if that's an appropriate way of telling implementers about these use cases, though. Cheers Lennart From nobody Thu Apr 12 17:23:04 2018 Return-Path: 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 E9B8612895E for ; Thu, 12 Apr 2018 17:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 tJ0rXoEbLmZX for ; Thu, 12 Apr 2018 17:22:58 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C475D1277BB for ; Thu, 12 Apr 2018 17:22:57 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id j18so4707196uae.12 for ; Thu, 12 Apr 2018 17:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XupH0e3J6hZ7RfahwAtMKXl+oJClle0649ItmzeTb0E=; b=IJaB0LfGj5Y4PHcdmsbJVXrm4S9asJisotHmd2ka557a5SFvfRqOeHpJ8yfNeyxMRe yIwPqc5A/j0V4/b9Xglz9W02hI9s8UPBDlyDNdulfQQfD/BoFsWUtNWac1eQQRigwyvj xh4akfc+YiTTx82F01UAIf/okhaRdnikQn6eN+i4mxdz5CPSxSuFcu7jDK3xSIM2Wbmv aqBKVLPFSYEyqaa9KT2zNX0z/N4dbVMgd4czLQTKB2ARxiExe94Pm+VNDS4m0/XTetsb 03Z4aeSbiAW0yjj90Sc4IvYe4eZN9Vfc8zkI0h2/ViFkHvBUYdLLANVXLKRYHWwv2rPx GcMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XupH0e3J6hZ7RfahwAtMKXl+oJClle0649ItmzeTb0E=; b=HEBZsCr+3ndrpfNVEHlYZMPGy+z9IiAIipsSabFJculrcazz/zpiIimYJb7RvnjsLY 1dID2Sg/YBN0bogu4s5it+63CAzUDO6AEMtzMBYE2Ysjvx2HLFMRPmYA4QOt2a4c6Yop nlu4tF28JO61zxfmF1adsqYoqJ78Y/wLssOm7Vrbq9Wym+3plLlt9tS+W9UU8PDapUIx FbwJZtiX1842gENj8fQTZ58Ih2evuzODbIEkzmcuPzOwQUWKUduC1G4TXlyM4aN6E825 ksWUS6pwtCb8QGcKE2EeOUBytKNUgSm7pWuhUGykVJbnD2K0yv8LUuItUiw8j3yQqJWh cXig== X-Gm-Message-State: ALQs6tDWBbhZ5ByPJvfF9Ma9KK8kytKoQHc6FWzYXIiHl8EwTBJL2vFC 9SoyRgvpYwj/Dr9mIs8M00w5rBodnN+e5KAzZ/KHeg== X-Google-Smtp-Source: AIpwx49IKfycksG5H+W2yZlwgQxGs/gDe2kjWpRvdy+/p2IvtAmgjKFVb4zMxbmUzNFWeEN4WrKKguvktd5DYDu0Z24= X-Received: by 10.176.21.1 with SMTP id o1mr2269351uae.60.1523578976344; Thu, 12 Apr 2018 17:22:56 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> In-Reply-To: From: Justin Uberti Date: Fri, 13 Apr 2018 00:22:45 +0000 Message-ID: To: Lennart Grahl Cc: Lorenzo Miniero , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a11463dccaca47c0569afdfac" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 00:23:01 -0000 --001a11463dccaca47c0569afdfac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Being non-interactive, it's not clear that those cases require Mode 1 though; they should work well even in Mode 2. I also don't think that suggesting "more appropriate means" is useful when we as a WG haven't been able to come up with any. Note also that between -02 and -03, we as a WG chose to remove a more explicit discussion of getUserMedia, namely this para: The getUserMedia suggestion takes into account that the user has provided some consent to the application already; that when doing so the user typically wants to engage in a conversational session, which benefits most from an optimal network path, and lastly, the fact that the underlying issue is complex and difficult to explain, making explicit consent for enumeration troublesome. If we're not going to talk about the upsides of the getUserMedia mechanism, I don't think we should have a lengthy discussion of downsides either. On Thu, Apr 12, 2018 at 4:49 PM Lennart Grahl wrote: > On 12.04.2018 14:41, Lorenzo Miniero wrote: > > On Thu, 12 Apr 2018 14:22:17 +0200 > > Lennart Grahl wrote: > > > >> On 12.04.2018 00:31, Sean Turner wrote: > >>>> On Apr 11, 2018, at 16:10, Adam Roach wrote: > >>>> > >>>> [as an individual] > >>>> > >>>> On 4/11/18 1:15 PM, Lennart Grahl wrote: > >>>>> Since I haven't seen a satisfactory response so far, let me > >>>>> rephrase this as a question: Can anyone explain to me why that > >>>>> approach is not considered a valid alternative to getUserMedia? > >>>> > >>>> > >>>> I think you're not getting a lot of response here because what > >>>> you're proposing is well within the bounds of what the current > >>>> document says. gUM is offered as a non-normative example, but > >>>> that's all it is. If you believe that document changes are in > >>>> order, perhaps a concrete proposal along the lines of "change the > >>>> text to be instead" or "add text at the end of section > >>>> " would produce more conversation. > >> > >> Thanks, this and the response from Bernard is good feedback that I > >> should provide a more concrete proposal next time. > >> > >>> As the draft=E2=80=99s Shepherd trying to figure out how to bring clo= sure > >>> on this issue, I like to offer a summary: > >>> > >>> There=E2=80=99s some discomfort with the use of the term =E2=80=9Cuse= r consent=E2=80=9D as > >>> well as the non-normative example provided for how to get it. The > >>> problem with changing the term to something else is "user consent" > >>> is a term of art; we can=E2=80=99t really qualify it with something l= ike > >>> =E2=80=9Cinformed=E2=80=9D, because we=E2=80=99d need to explain what= that means (and well > >>> GDPR =E2=80=A6), and; frankly the term is used extensively in the oth= er > >>> security draft that we pruned ip-handling from. The problem with > >>> changing the non-normative example is that there don=E2=80=99t seem t= o be > >>> other attractive/realistic alternatives. > >>> > >>> What I=E2=80=99d like to do is remind everybody that we pruned this d= raft > >>> from the other security drafts to allow it to be updated faster > >>> because it=E2=80=99s about a much narrower subject. With this in min= d and > >>> Bernard=E2=80=99s long list of questions, I would like to propose tha= t we:* > >>> > >>> 1) Add another sentence (from Tim) that indicates there are other > >>> alternatives: > >>> > >>> Alternatively implementations can provide a separate > >>> mechanism to obtain user consent. > >>> > >>> 2) Progress the draft out of the WG.* > >>> > >>> 3) Update/Obsolete this draft, when a much superior alternative > >>> emerges. > >>> > >>> spt > >>> > >>> * Also "hold your nose" if you=E2=80=99re sad about this proposal but= are > >>> willing to begrudgingly live with the rough consensus; it=E2=80=99s r= ough > >>> and we noted this in the Shepherd write-up. > >>> > >>> ** Remember that during the IETF LC we (or somebody in the wider > >>> IETF community) might come up with something during the IETF LC. > >> > >> I realise I've joined a tad late and it should be clear by now that I > >> have a strong reluctance when it comes to using getUserMedia for the > >> purpose of getting consent to use mode 1. But you are correct, it is > >> non-normative and I'm more irritated by the implementations that don't > >> provide an alternative than this document. Still, I would appreciate > >> if the sentence from Tim you mentioned in 1) will be added. > >> > >> Regarding 3): Like Bernard, I'm unsure how to determine a "superior > >> alternative" (especially in the context of a non-normative section). > >> > > > > > > Since there seems to be a call for proposed text: > > > > The details of this consent are left to the implementation; one > > potential mechanism is to tie this consent to getUserMedia > > consent. It should be noted, though, that getUserMedia > > consent is typically only required when users are supposed to > > share media content from their local devices. This may not > > always be the case, e.g., in scenarios where users will only > > be receiving media (e.g., a broadcast), or when > > PeerConnections are created for the sole purpose of setting up > > datachannels. Requiring getUserMedia consent when it's not > > really needed may end up discouraging users from establishing > > a media session, or getting unwarranted access to more > > information they meant to share. As such, alternative and more > > appropriate means for getting user consent for Mode 1 are > > suggested. > > > > Probably overly verbose, but it voices my (and I think Lennart's) > > concern with the current text. > > Likely a verbose version of https://github.com/juberti/draughts/pull/98. > But I appreciate and would agree with that since it clarifies that some > non-obvious use cases exists that we have found throughout the years > where getUserMedia is painful (if anything). I don't know if that's an > appropriate way of telling implementers about these use cases, though. > > Cheers > Lennart > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11463dccaca47c0569afdfac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Being non-interactive, it's not clear that those cases= require Mode 1 though; they should work well even in Mode 2. I also don= 9;t think that suggesting "more appropriate means" is useful when= we as a WG haven't been able to come up with any.

N= ote also that between -02 and -03, we as a WG chose to remove a more explic= it discussion of getUserMedia, namely this para:

<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:no= rmal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-al= ign:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decorat= ion-style:initial;text-decoration-color:initial"> The getUserMedia suggestion takes into account that the user has provided some consent to the application already; that when doing so the user typically wants to engage in a conversational session, which benefits most from an optimal network path, and lastly, the fact that the underlying issue is complex and difficult to explain, making explicit consent for enumeration troublesome.

If we're not going to talk =
about the upsides of the getUserMedia mechanism, I don't think we shoul=
d have a lengthy discussion of downsides either.

=


On Thu= , Apr 12, 2018 at 4:49 PM Lennart Grahl <lennart.grahl@gmail.com> wrote:
On 12.04.2018 14:41, Lorenzo Miniero wrote:
> On Thu, 12 Apr 2018 14:22:17 +0200
> Lennart Grahl <lennart.grahl@gmail.com> wrote:
>
>> On 12.04.2018 00:31, Sean Turner wrote:
>>>> On Apr 11, 2018, at 16:10, Adam Roach <adam@nostrum.com> wrote:
>>>>
>>>> [as an individual]
>>>>
>>>> On 4/11/18 1:15 PM, Lennart Grahl wrote:=C2=A0
>>>>> Since I haven't seen a satisfactory response so fa= r, let me
>>>>> rephrase this as a question: Can anyone explain to me = why that
>>>>> approach is not considered a valid alternative to getU= serMedia?=C2=A0
>>>>
>>>>
>>>> I think you're not getting a lot of response here beca= use what
>>>> you're proposing is well within the bounds of what the= current
>>>> document says. gUM is offered as a non-normative example, = but
>>>> that's all it is. If you believe that document changes= are in
>>>> order, perhaps a concrete proposal along the lines of &quo= t;change the
>>>> text <x> to be <y> instead" or "add = text <z> at the end of section
>>>> <q>" would produce more conversation.=C2=A0 >>
>> Thanks, this and the response from Bernard is good feedback that I=
>> should provide a more concrete proposal next time.
>>
>>> As the draft=E2=80=99s Shepherd trying to figure out how to br= ing closure
>>> on this issue, I like to offer a summary:
>>>
>>> There=E2=80=99s some discomfort with the use of the term =E2= =80=9Cuser consent=E2=80=9D as
>>> well as the non-normative example provided for how to get it. = The
>>> problem with changing the term to something else is "user= consent"
>>> is a term of art; we can=E2=80=99t really qualify it with some= thing like
>>> =E2=80=9Cinformed=E2=80=9D, because we=E2=80=99d need to expla= in what that means (and well
>>> GDPR =E2=80=A6), and; frankly the term is used extensively in = the other
>>> security draft that we pruned ip-handling from.=C2=A0 The prob= lem with
>>> changing the non-normative example is that there don=E2=80=99t= seem to be
>>> other attractive/realistic alternatives.
>>>
>>> What I=E2=80=99d like to do is remind everybody that we pruned= this draft
>>> from the other security drafts to allow it to be updated faste= r
>>> because it=E2=80=99s about a much narrower subject.=C2=A0 With= this in mind and
>>> Bernard=E2=80=99s long list of questions, I would like to prop= ose that we:*
>>>
>>> 1) Add another sentence (from Tim) that indicates there are ot= her
>>> alternatives:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Alternatively implementations can pr= ovide a separate
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism to obtain user consent. >>>
>>> 2) Progress the draft out of the WG.*
>>>
>>> 3) Update/Obsolete this draft, when a much superior alternativ= e
>>> emerges.
>>>
>>> spt
>>>
>>> * Also "hold your nose" if you=E2=80=99re sad about = this proposal but are
>>> willing to begrudgingly live with the rough consensus; it=E2= =80=99s rough
>>> and we noted this in the Shepherd write-up.
>>>
>>> ** Remember that during the IETF LC we (or somebody in the wid= er
>>> IETF community) might come up with something during the IETF L= C.=C2=A0
>>
>> I realise I've joined a tad late and it should be clear by now= that I
>> have a strong reluctance when it comes to using getUserMedia for t= he
>> purpose of getting consent to use mode 1. But you are correct, it = is
>> non-normative and I'm more irritated by the implementations th= at don't
>> provide an alternative than this document. Still, I would apprecia= te
>> if the sentence from Tim you mentioned in 1) will be added.
>>
>> Regarding 3): Like Bernard, I'm unsure how to determine a &quo= t;superior
>> alternative" (especially in the context of a non-normative se= ction).
>>
>
>
> Since there seems to be a call for proposed text:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The details of this consent are left to the = implementation; one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0potential mechanism is to tie this consent t= o getUserMedia
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consent.=C2=A0 It should be noted, though, t= hat getUserMedia
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consent is typically only required when user= s are supposed to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0share media content from their local devices= . This may not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0always be the case, e.g., in scenarios where= users will only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be receiving media (e.g., a broadcast), or w= hen
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PeerConnections are created for the sole pur= pose of setting up
>=C2=A0 =C2=A0 =C2=A0 =C2=A0datachannels. Requiring getUserMedia consent= when it's not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0really needed may end up discouraging users = from establishing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a media session, or getting unwarranted acce= ss to more
>=C2=A0 =C2=A0 =C2=A0 =C2=A0information they meant to share. As such, al= ternative and more
>=C2=A0 =C2=A0 =C2=A0 =C2=A0appropriate means for getting user consent f= or Mode 1 are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0suggested.
>
> Probably overly verbose, but it voices my (and I think Lennart's)<= br> > concern with the current text.

Likely a verbose version of https://github.com/juberti/dr= aughts/pull/98.
But I appreciate and would agree with that since it clarifies that some
non-obvious use cases exists that we have found throughout the years
where getUserMedia is painful (if anything). I don't know if that's= an
appropriate way of telling implementers about these use cases, though.

Cheers
Lennart

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--001a11463dccaca47c0569afdfac-- From nobody Thu Apr 12 21:28:29 2018 Return-Path: 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 321E0126BF0 for ; Thu, 12 Apr 2018 21:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 5gTTfDOwsvG5 for ; Thu, 12 Apr 2018 21:28:26 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8C2124239 for ; Thu, 12 Apr 2018 21:28:26 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id q26so4978324uab.0 for ; Thu, 12 Apr 2018 21:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JV1PfHlXgS5MYxrzAfgnp/W04MCO1I5itbSbFlGzffM=; b=lqudieR7zG6xeVW5HHsEPQUaTsvTCSEwARzUqGY8xrmYDZsa8bQ7sn2FVY8tJTs8Bu pLLbtMF27FmBEIchCz/py9bdD7aAyl8zeCZy1EAOxbOKGHdcC0oJAbEYjJ86YAtxDBiR P9K4cwDF2e02ILPrGLTEGZQD05ATU2NCdASl7CbqBkckgoV7xliOa78waEYRxo2/TmHp MD6DOkZyfCvdY9mErEhlmkSBB/m+1x8Qe3sVXHwmoXGYZfayvZoaUXAVnGes2363qWqP tNZPHIJrHOBO5BCCYbrEJpSQunvRMY/0cHxd/9I6HNNG88EDJ/jV28h7uEkh8XfIOzJT OQDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JV1PfHlXgS5MYxrzAfgnp/W04MCO1I5itbSbFlGzffM=; b=L9iTXnngrkyutuEeBwchj0ylIejJFjauz8BgfACZn4tRWO14EQd2ZVN+RWLuttQvzt xa664dG/L30feBgb9YQ9b3h1Dkk04xMx1r6s9b9vvvgSCVf99H4UbhjNp/OLIpSXBfS/ RBAuhuA7vNp3lJDyastPk0T5Mk1wjC8i2G5hyZwxhKjcogBX7Atst8oYiu3U94AASy21 d2SjNGyRHsOMrl56ILvrdVWiweLpsvEkrdcoqAXllRX/c0V+GAGgMVndlpXu9k66rlQz yDWxjBSO08xrCiexsYwlrBO1T5+RxUli0zB2oABXAnXqQ/dgIlDBzTzGkHQBroTrBKvF Aa8Q== X-Gm-Message-State: ALQs6tAjJRDOLelH+h0fZwJJeE4f8DeeO+i782S/RJ1fL4dHkijbFRNb gqO0+x13sGHq0DxoACzGvofInt7ORhYzzyGRivsLcw== X-Google-Smtp-Source: AIpwx4/vkQs3fEY2iOzJzeOhXbPNoya64HqkzltNy/b4nW5qYmq8Nt9liKiYXM2zFekpAWv6y/BvTKC19R46tVEFoJ4= X-Received: by 10.176.28.22 with SMTP id a22mr2707629uaj.146.1523593704835; Thu, 12 Apr 2018 21:28:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Thu, 12 Apr 2018 21:28:24 -0700 (PDT) In-Reply-To: <2302437f-68b9-b68f-ac14-011f4cf4066d@gmail.com> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> <1683BDE2-6E74-40BD-966B-ED7DFEB58083@lurchi.franken.de> <2302437f-68b9-b68f-ac14-011f4cf4066d@gmail.com> From: Taylor Brandstetter Date: Thu, 12 Apr 2018 21:28:24 -0700 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF , Michael Tuexen Content-Type: multipart/alternative; boundary="089e0820667c8fa3320569b34da8" Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 04:28:28 -0000 --089e0820667c8fa3320569b34da8 Content-Type: text/plain; charset="UTF-8" > > FWIW, I don't believe any browser would count as an implementation with > limited resources. > If so, it could say "browsers MUST attempt to negotiate 65535 streams, but be prepared for negotiating fewer, e.g. when communicating with a non-WebRTC endpoint with limited resources"? Or could just add an explanation for the SHOULD; I don't have strong opinions about this. On Thu, Apr 12, 2018 at 4:22 PM, Lennart Grahl wrote: > On 11.04.2018 23:24, Michael Tuexen wrote: > >> On 11. Apr 2018, at 22:29, Taylor Brandstetter > wrote: > >> > >> I listened to the recording, and this was the main point being > discussed, but the conclusion seemed to be "efficient implementations > shouldn't use much (or any) memory for unused streams; we shouldn't make > sacrifices in the protocol just to reduce implementation complexity." > > You can implement it in a way to not use much memory for unused streams. > However, you need some memory > > for stream you use. That is why I referred to the number of streams used > in parallel. > > So, implementations with limited resources may still choose to negotiate > less than that to prevent running into exhausting their resources. That > makes sense to me, so I would withdraw the request to make it a MUST. > Could this explanation be added as a comment to the draft, so it's clear > why it's not a MUST? > > FWIW, I don't believe any browser would count as an implementation with > limited resources. But I get that there are other implementations > outside of the browser and it may make sense there to limit the amount > of streams. And since we can interoperate with them, we need to handle > it some way or another in the W3C WebRTC spec. > > Taylor, any objections? > > Cheers > Lennart > --089e0820667c8fa3320569b34da8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, I don't believe any browser would count as an = implementation with
limited resources.

If so, it could say "browsers M= UST attempt to negotiate 65535 streams, but be prepared for negotiating few= er, e.g. when communicating with a non-WebRTC endpoint with limited resourc= es"?

Or could just add an explanation for the= SHOULD; I don't have strong opinions about this.

On Thu, Apr 12, 2018 at 4:2= 2 PM, Lennart Grahl <lennart.grahl@gmail.com> wrote:
On 11.04.2018 23:24, Mich= ael Tuexen wrote:
>> On 11. Apr 2018, at 22:29, Taylor Brandstetter <deadbeef@google.com> wrote:
>>
>> I listened to the recording, and this was the main point being dis= cussed, but the conclusion seemed to be "efficient implementations sho= uldn't use much (or any) memory for unused streams; we shouldn't ma= ke sacrifices in the protocol just to reduce implementation complexity.&quo= t;
> You can implement it in a way to not use much memory for unused stream= s. However, you need some memory
> for stream you use. That is why I referred to the number of streams us= ed in parallel.

So, implementations with limited resources may still choose to negot= iate
less than that to prevent running into exhausting their resources. That
makes sense to me, so I would withdraw the request to make it a MUST.
Could this explanation be added as a comment to the draft, so it's clea= r
why it's not a MUST?

FWIW, I don't believe any browser would count as an implementation with=
limited resources. But I get that there are other implementations
outside of the browser and it may make sense there to limit the amount
of streams. And since we can interoperate with them, we need to handle
it some way or another in the W3C WebRTC spec.

Taylor, any objections?

Cheers
Lennart

--089e0820667c8fa3320569b34da8-- From nobody Thu Apr 12 21:52:34 2018 Return-Path: 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 BEC29124239 for ; Thu, 12 Apr 2018 21:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 s4ijvjQWsaaO for ; Thu, 12 Apr 2018 21:52:30 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D31126DFB for ; Thu, 12 Apr 2018 21:52:30 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id a39-v6so5381486pla.10 for ; Thu, 12 Apr 2018 21:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8vkNX7yr65rkUE2QtXTqMY0h79brkKc1q7UXStKLoWQ=; b=GJcTty45wIvk2Q/zKoA6ZcJHKSRzgOh48/hZMPw7KHDTaJzLnEG/yIo5jdUB35anUK K63mSIBWzeU3UYCP+6U6H6gs+LMZMoxB8xALP2PrSYdEQ/6u9KCRbvuPlYc/rw8D3I8a 7jCP2r+dRprzZcYGI6T0f7gRyJieucju8S9hA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8vkNX7yr65rkUE2QtXTqMY0h79brkKc1q7UXStKLoWQ=; b=Q6RP2Ki1XnXzM/ojxLI9uvSjCLMaJCCZkShyGeKJ0TiKNhnmaO18/R9z+mPWn00EE+ ycFHY3g3eooS8gSlOxMmTrVx2mR97pB0bzghaMOhMhw0sw2J7G4bpDnOTX/JLiH0jXIj meeGtftpk0ToN75vEwG1nqeOaCI4Vae3nvM4SHnmPxgv7E0BaH42cOf78jcVcqLJJ9Sz QnYtLqk6q6qzNGR4NZ7RMz3S1RIWo9K6KGC2Q5lc0DdwkmbDIm6y/09CL8wOLk1+DUEk Qz/6KI8GwHFyu5RtuQlefihGhKNfnmgr33DB6zuiDMddtEa8h86fzyuWcbJPNxr2GqI2 eKJw== X-Gm-Message-State: ALQs6tCEsrFTkE5LKKh93s3bW8qVYhgV2JYwgSWfR010n9l5+W/0G9Do cESSYtyb6AIGsGbPKF4lNzU7jwieVZc= X-Google-Smtp-Source: AIpwx49uuHAhhR/I9DC6s5BszLMw/CxdGdHiWv0zaTr2Yfdgr24v6TkduvwrDjs6M7e35f00SEinwg== X-Received: by 2002:a17:902:aa90:: with SMTP id d16-v6mr3771876plr.189.1523595149785; Thu, 12 Apr 2018 21:52:29 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:f5d6:bb84:905c:8725? ([2601:647:4600:3f31:f5d6:bb84:905c:8725]) by smtp.gmail.com with ESMTPSA id q15sm11173920pfi.140.2018.04.12.21.52.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 21:52:28 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D4B9DF0C-3841-4807-A892-0004932E4182"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 12 Apr 2018 21:52:26 -0700 In-Reply-To: Cc: RTCWeb IETF To: Sean Turner References: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 04:52:32 -0000 --Apple-Mail=_D4B9DF0C-3841-4807-A892-0004932E4182 Content-Type: multipart/alternative; boundary="Apple-Mail=_98BBCE14-E684-498D-8750-3676E2886932" --Apple-Mail=_98BBCE14-E684-498D-8750-3676E2886932 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 12, 2018, at 06:45, Sean Turner wrote: > 0) More text to address a linkability concern: >=20 > As a practical matter, if the browser were to use the same = certificate > for multiple origins, then it would create a massive privacy problem > that enables linkability (aka user tracking). I couldn't find that > written down, but I thought it was. If it isn't written down, then = we > should correct that. >=20 > I actually think this is basically covered here: > = https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.1 > But want to make sure others agree: Agreed. > 1) Tweak protocol to include an identifier to prevent reuse of = assertion on every RTCPeerConnection: >=20 To be honest I=E2=80=99m actually confused by Martin=E2=80=99s = statement. > More complex sites frequently generate multiple RTCPeerConnection > instances for their communications, especially for group > conversations. If the browser requests an assertion once and they = use > that value for every RTCPeerConnection, then that's OK. This sentence sounds to me like it would/should be okay for = pages/service to re-use identity assertions. > =46rom my > perspective, I would be happy modifying the protocol to include an > identifier and prevent that; for this the IdP can use caching or its > local storage. While this sounds to me like the opposite. > So, what would that look like? The tls-id from = https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-32 = could serve = that purpose. Best Nils Ohlmeier >=20 >=20 > Did I miss anything else that needs to be addressed? >=20 > spt >=20 > [0] = https://mailarchive.ietf.org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7jXEw >=20 >> On Mar 12, 2018, at 19:08, Sean Turner wrote: >>=20 >> All, >>=20 >> This is the WGLC for the =E2=80=9CWebRTC Security Architecture=E2=80=9D= draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. Please = review the draft and send your comments to this list by 2359UTC on April = 6th, 2018. >>=20 >> Note the gh repo is here: >> https://github.com/rtcweb-wg/security-arch >>=20 >> Thanks, >> C/T/S >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_98BBCE14-E684-498D-8750-3676E2886932 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 12, 2018, at 06:45, Sean Turner <sean@sn3rd.com> = wrote:
0) More text to address a = linkability concern:

 As a practical = matter, if the browser were to use the same certificate
=  for multiple origins, then it would create a massive privacy = problem
 that enables linkability (aka user = tracking).  I couldn't find that
 written down, = but I thought it was.  If it isn't written down, then we
 should correct that.

I = actually think this is basically covered here:
https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#secti= on-4.4.1
But want to make sure others agree:

Agreed.

1) Tweak protocol to include an identifier to = prevent reuse of assertion on every RTCPeerConnection:


To be = honest I=E2=80=99m actually confused by Martin=E2=80=99s = statement.

  More complex sites = frequently generate multiple RTCPeerConnection
=  instances for their communications, especially for group
 conversations.  If the browser requests an = assertion once and they use
 that value for every = RTCPeerConnection, then that's OK.

This sentence sounds to me like it would/should be okay = for pages/service to re-use identity assertions.

 =46rom my
 perspective, I would be = happy modifying the protocol to include an
=  identifier and prevent that; for this the IdP can use caching or = its
 local storage.

While this = sounds to me like the opposite.

So, what would = that look like?

The tls-id from https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-32&n= bsp;could serve that purpose.

Best
  Nils Ohlmeier



Did I miss anything else that = needs to be addressed?

spt

[0] https://mailarchive.ietf.org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsY= FrDw7jXEw

On Mar 12, 2018, at 19:08, Sean Turner <sean@sn3rd.com> = wrote:

All,

This= is the WGLC for the =E2=80=9CWebRTC Security Architecture=E2=80=9D = draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/.  Please review the draft and send your comments to this list by = 2359UTC on April 6th, 2018.

Note the gh = repo is here:
https://github.com/rtcweb-wg/security-arch

Thanks,
C/T/S

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_98BBCE14-E684-498D-8750-3676E2886932-- --Apple-Mail=_D4B9DF0C-3841-4807-A892-0004932E4182 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrQN4oACgkQY2o/VmzJ +KEfBxAAkQob5g5C1I9bIJV9w6BCuczjzxW+lYAbk9J3jQLoVZo11AAWsBnnFFDr 56OhzGCTpFWlAChKI9Nt3/BBfu0X1qNoCB+VgxdD7MT0Y6TfzT/y3D9AbNugu/um TgnaDkAcwRgxJSr6YAPeZLRWY7t6fCTRw2eaBDJhsmF/vNrRf38ZHnzQJ135Ewcg SAvE+7FKqu2IDRFznnnzxt0vFOubF+xIcqtHIIhdK6HEPoWS7x0hAY7RYFMA9U7r 6ARExuseCAVvr+9AGeqVXsBJYL5fFbHNFWqBmX5QoohIqkX1sfrrtRE++nenFzP0 Bdv8gYzWHhouUaKPVorUEkjuy9nhVG2ehpFYCaOkv8hhWg8O+YMIWE84JLV7AmrT pdDSoJMGOpTiW20tOZG3d35i1ETs2zN4ghconTXhfw6tuMpPicabWtB4I8qnBmSI FR5CbqNXQCT8Wn2wKb3Ub8QH1f2w1AFO+0PHK+xRcjzsUYeJPC2J2Xm44ck0n8uD qvTPm0jfY+x77uhrovzdCt0owg+zbO39X458qm+irYnMMIY/u/KVB4umWLQa0coZ 9C9S5E1K9dNXT1nLZLREKI4mUwvKtgJQNDD+ru4W9XpoA1ZaKHVShQqHxq6fWW2q jCsTmM0aOfp+2LAmwUfJ9k9j3Rho29001IUcjPpxg17eDBg85FA= =1M63 -----END PGP SIGNATURE----- --Apple-Mail=_D4B9DF0C-3841-4807-A892-0004932E4182-- From nobody Thu Apr 12 23:03:35 2018 Return-Path: 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 020D6126D45 for ; Thu, 12 Apr 2018 23:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 xXewfGTE9xCR for ; Thu, 12 Apr 2018 23:03:31 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433E7126C22 for ; Thu, 12 Apr 2018 23:03:31 -0700 (PDT) Received: from [IPv6:2003:cd:6f00:5e00:64b7:97b8:c253:28cb] (p200300CD6F005E0064B797B8C25328CB.dip0.t-ipconnect.de [IPv6:2003:cd:6f00:5e00:64b7:97b8:c253:28cb]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 6BFDC721E281E; Fri, 13 Apr 2018 08:03:28 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Michael Tuexen In-Reply-To: Date: Fri, 13 Apr 2018 08:03:27 +0200 Cc: Lennart Grahl , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <4FFCC73B-7BFB-4A32-9B13-C4C0F5BA7408@lurchi.franken.de> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> <1683BDE2-6E74-40BD-966B-ED7DFEB58083@lurchi.franken.de> <2302437f-68b9-b68f-ac14-011f4cf4066d@gmail.com> To: Taylor Brandstetter X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 06:03:34 -0000 > On 13. Apr 2018, at 06:28, Taylor Brandstetter = wrote: >=20 > FWIW, I don't believe any browser would count as an implementation = with > limited resources. >=20 > If so, it could say "browsers MUST attempt to negotiate 65535 streams, = but be prepared for negotiating fewer, e.g. when communicating with a = non-WebRTC endpoint with limited resources"? >=20 > Or could just add an explanation for the SHOULD; I don't have strong = opinions about this. You can make a text suggestion... I would vote for an explanation of the = SHOULD. However, please note that the ID is in the RFC Editor queue. So it is = not just updating an ID. I'm not sure which changes except for the usual = AUTH48 changes can be done anymore. Best regards Michael >=20 > On Thu, Apr 12, 2018 at 4:22 PM, Lennart Grahl = wrote: > On 11.04.2018 23:24, Michael Tuexen wrote: > >> On 11. Apr 2018, at 22:29, Taylor Brandstetter = wrote: > >> > >> I listened to the recording, and this was the main point being = discussed, but the conclusion seemed to be "efficient implementations = shouldn't use much (or any) memory for unused streams; we shouldn't make = sacrifices in the protocol just to reduce implementation complexity." > > You can implement it in a way to not use much memory for unused = streams. However, you need some memory > > for stream you use. That is why I referred to the number of streams = used in parallel. >=20 > So, implementations with limited resources may still choose to = negotiate > less than that to prevent running into exhausting their resources. = That > makes sense to me, so I would withdraw the request to make it a MUST. > Could this explanation be added as a comment to the draft, so it's = clear > why it's not a MUST? >=20 > FWIW, I don't believe any browser would count as an implementation = with > limited resources. But I get that there are other implementations > outside of the browser and it may make sense there to limit the amount > of streams. And since we can interoperate with them, we need to handle > it some way or another in the W3C WebRTC spec. >=20 > Taylor, any objections? >=20 > Cheers > Lennart >=20 From nobody Thu Apr 12 23:59:22 2018 Return-Path: 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 2FFB7127137 for ; Thu, 12 Apr 2018 23:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 DKxVgKnijCfY for ; Thu, 12 Apr 2018 23:59:18 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) (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 37A2F126D45 for ; Thu, 12 Apr 2018 23:59:18 -0700 (PDT) Received: (qmail 55135 invoked from network); 13 Apr 2018 06:59:16 -0000 X-APM-Authkey: 255286/0(159927/0) 73 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 13 Apr 2018 06:59:16 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1CB7518A06E9; Fri, 13 Apr 2018 07:59:16 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ErSuprRcdzQ8; Fri, 13 Apr 2018 07:59:16 +0100 (BST) Received: from [192.168.0.3] (cable-82-119-15-228.cust.telecolumbus.net [82.119.15.228]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id D19BC18A0285; Fri, 13 Apr 2018 07:59:15 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: westhawk In-Reply-To: Date: Fri, 13 Apr 2018 08:59:13 +0200 Cc: Lennart Grahl , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> To: Justin Uberti X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 06:59:21 -0000 > On 13 Apr 2018, at 02:22, Justin Uberti = wrote: >=20 > Being non-interactive, it's not clear that those cases require Mode 1 = though; they should work well even in Mode 2. I also don't think that = suggesting "more appropriate means" is useful when we as a WG haven't = been able to come up with any. Whoa there! Non interactive, that=E2=80=99s a big step from = non-conversational ! So one current use-case is adjusting room lights over the data channel. = You can literally see latency - an unnecessary cloud round-trip is = entirely visible. Another is driving a droid over the datachannel using it=E2=80=99s = camera to feed live video to see where it is going=20 - again totally interactive, just not using local media at the user=E2=80=99= s end (although we do use the=20 motion sensors to give a steering wheel feel) - latency here causes = crashes! A third one is baby cams, where again the video feed is one-way but = you=E2=80=99d really like to keep the media on the home wifi if possible for cost (and privacy) reasons. In all these I=E2=80=99ll have to introduce an otherwise needless GUM = request to get the network behaviour I want.=20 Perhaps I should present some of these non-call based usecases at a = future F2F so that folks get a sense of the possibilities. Tim.=20 From nobody Thu Apr 12 23:59:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDCE12711A for ; Thu, 12 Apr 2018 23:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523602761; bh=39X/eVn5+VNEWjxfMwUYL+QEDzngOUZR5Ukuo8nIVK4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=I9vZrZU1p+RBon8OFqUiU3DJGg6eijUY58shNcw3dCu8rJT/ZiXYabcZrM9Fhsc3D jnD+3WdbLYjR2nQN2k8hb38zTrZBAV1rGdpQN090c3qmBlaevXpZp+HvXS2Rz4CoSY FQJDPNMKkikh7rLOb0DoAIyxTP3x3i+dpCCKXKZs= X-Mailbox-Line: From thp@westhawk.co.uk Thu Apr 12 23:59:21 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8232127058; Thu, 12 Apr 2018 23:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523602760; bh=39X/eVn5+VNEWjxfMwUYL+QEDzngOUZR5Ukuo8nIVK4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Rb+kuTwHXpwBnBtlax0y8ZVxrvEI7iMrSwowWNe6vq5JCS8RpIyTG/7xB8s40AidY O24bZnTZywx/DlzGITj0SgzyKy6rIfwCo2le7VWIMtDY8rT4uLEak0lcBTh16gqDOF 30NYG0Ou4Ty8efNGeblFmxFps/t/sQaDbQ4i4h3o= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13FD126E64 for ; Thu, 12 Apr 2018 23:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 AVXWgrmDn9i0 for ; Thu, 12 Apr 2018 23:59:18 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) (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 44B25127058 for ; Thu, 12 Apr 2018 23:59:18 -0700 (PDT) Received: (qmail 55135 invoked from network); 13 Apr 2018 06:59:16 -0000 X-APM-Authkey: 255286/0(159927/0) 73 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 13 Apr 2018 06:59:16 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1CB7518A06E9; Fri, 13 Apr 2018 07:59:16 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ErSuprRcdzQ8; Fri, 13 Apr 2018 07:59:16 +0100 (BST) Received: from [192.168.0.3] (cable-82-119-15-228.cust.telecolumbus.net [82.119.15.228]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id D19BC18A0285; Fri, 13 Apr 2018 07:59:15 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: westhawk In-Reply-To: Date: Fri, 13 Apr 2018 08:59:13 +0200 Cc: Lennart Grahl , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> X-Mailer: Apple Mail (2.3445.6.18) To: Justin Uberti Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 06:59:21 -0000 > On 13 Apr 2018, at 02:22, Justin Uberti = wrote: >=20 > Being non-interactive, it's not clear that those cases require Mode 1 = though; they should work well even in Mode 2. I also don't think that = suggesting "more appropriate means" is useful when we as a WG haven't = been able to come up with any. Whoa there! Non interactive, that=E2=80=99s a big step from = non-conversational ! So one current use-case is adjusting room lights over the data channel. = You can literally see latency - an unnecessary cloud round-trip is = entirely visible. Another is driving a droid over the datachannel using it=E2=80=99s = camera to feed live video to see where it is going=20 - again totally interactive, just not using local media at the user=E2=80=99= s end (although we do use the=20 motion sensors to give a steering wheel feel) - latency here causes = crashes! A third one is baby cams, where again the video feed is one-way but = you=E2=80=99d really like to keep the media on the home wifi if possible for cost (and privacy) reasons. In all these I=E2=80=99ll have to introduce an otherwise needless GUM = request to get the network behaviour I want.=20 Perhaps I should present some of these non-call based usecases at a = future F2F so that folks get a sense of the possibilities. Tim.=20 From nobody Fri Apr 13 01:23:42 2018 Return-Path: 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 2944412D7F9 for ; Fri, 13 Apr 2018 01:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CsL3phkIcXBd for ; Fri, 13 Apr 2018 01:23:38 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178DD1241FC for ; Fri, 13 Apr 2018 01:23:38 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id w2so6078335wmw.1 for ; Fri, 13 Apr 2018 01:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a97n4shaxkM+l+DeqbeHbgz8bndYSMBed4HCIQ9RH0U=; b=sFZSj4jQxZlx51CXirzMqNbnNC/62ch2/igOwCOUHxcfMG3t/fqZ3ZstOWJQffyQhb JXW/J77QgWzAvSUitxor4Lxafs7jTN4sVP0qQtkWmjzykCiuCPf7nUjpfgGw9uFHcIks amFtnKoq5epSHlxyO6kyjcuhcmp5ftrre7r1AifnSMecMZ9FBBq9mQE7RoKIJ9DlvJJb xDQyJ5/kvHZm6gp0/9wwHRTuJQqO2+sWsAwXoa/tTfd6g5/byhrRoUAHfs1ovfkh7UeA hR9aGTE7v4ffNRPoNhJiKpfF03LjvfaNfoQH92hIqxZDMS97CTQH8cPOh7h7QkbfmNej /OXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a97n4shaxkM+l+DeqbeHbgz8bndYSMBed4HCIQ9RH0U=; b=WrhuNQD1ScDmka46iqY0vVQVpL/Q4RQRmr0Exk5IUP1Isggg83JNnkmCJrOAvCoIqU x+0MIBkCx6V9I1qwDqg8kztXNoBBsoNt4SI3t6WX3zSvp1IaZzlvnqBt/qiS8VUPg2Cz iOenF1eXXAZ+1SJwF4Oqf2T8O7b6lIGxwhwYUUdF4eparbtTkzUUsAypNLH7EVqmB7rg /HQnSq6yuY1p1NdJIRKEoerkEF5l4Y8Zr/yYxM/wW9of3oBv00pCAw/4qtY/FAU9YH08 QSUpWf55i1goRYLW4x+Xw2W/EFNxGJOj5o5f9kNInqU5g0GCVIs8/6+hvGtHChiEVp9o ytbA== X-Gm-Message-State: ALQs6tCUJOl2GJWEFhEfqdagzx0CcYS7XUxUf4GmMYgQICnXC57gn43E xNKtUMDmOb5/IWVlPwor0HFwBTpEcAFbBd3yJVMIlg== X-Google-Smtp-Source: AIpwx481u/A+S4yeBJNZKCZuUWwAPnE0KU9MwkfuLgYxq6EjoDaHzKoM+CxfiinvG1NUAOoVvzuqE/EGFNapwtGn/SA= X-Received: by 10.80.170.29 with SMTP id o29mr18687465edc.74.1523607816532; Fri, 13 Apr 2018 01:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.184.161 with HTTP; Fri, 13 Apr 2018 01:23:16 -0700 (PDT) In-Reply-To: <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> From: Balwant Bisht Date: Fri, 13 Apr 2018 13:53:16 +0530 Message-ID: To: westhawk Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c0ddc0cae77860569b696cb" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 08:23:41 -0000 --94eb2c0ddc0cae77860569b696cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also what will happen when user have disabled camera & microphone on his system, don't have any or G Suite Admin have disabled devices on Chromebook and user just want to see a live event (webinar, baby cam etc). Regards Balwant Bisht On Fri, Apr 13, 2018 at 12:29 PM, westhawk wrote: > > > > On 13 Apr 2018, at 02:22, Justin Uberti ietf.org> wrote: > > > > Being non-interactive, it's not clear that those cases require Mode 1 > though; they should work well even in Mode 2. I also don't think that > suggesting "more appropriate means" is useful when we as a WG haven't bee= n > able to come up with any. > > Whoa there! Non interactive, that=E2=80=99s a big step from non-conversat= ional ! > So one current use-case is adjusting room lights over the data channel. > You can literally see latency - an unnecessary cloud round-trip is entire= ly > visible. > > Another is driving a droid over the datachannel using it=E2=80=99s camera= to feed > live video to see where it is going > - again totally interactive, just not using local media at the user=E2=80= =99s end > (although we do use the > motion sensors to give a steering wheel feel) - latency here causes > crashes! > > A third one is baby cams, where again the video feed is one-way but you= =E2=80=99d > really like to keep the media on the home wifi > if possible for cost (and privacy) reasons. > > In all these I=E2=80=99ll have to introduce an otherwise needless GUM req= uest to > get the network behaviour I want. > > Perhaps I should present some of these non-call based usecases at a futur= e > F2F so that folks get a sense of the possibilities. > > Tim. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c0ddc0cae77860569b696cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also what will happen when user have disabled camera &= microphone on his system, don't have any or G Suite Admin have disable= d devices on Chromebook and user just want to see a live event (webinar, ba= by cam etc).

= Regards
Balwant Bisht


On Fri, Apr 13, 2018 at 12:29 PM, westhawk <= span dir=3D"ltr"><thp@westhawk.co.uk> wrote:


> On 13 Apr 2018, at 02:22, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wro= te:
>
> Being non-interactive, it's not clear that those cases require Mod= e 1 though; they should work well even in Mode 2. I also don't think th= at suggesting "more appropriate means" is useful when we as a WG = haven't been able to come up with any.

Whoa there! Non interactive, that=E2=80=99s a big step from non-conv= ersational !
So one current use-case is adjusting room lights over the data channel. You= can literally see latency - an unnecessary cloud round-trip is entirely visible.

Another is driving a droid over the datachannel using it=E2=80=99s camera t= o feed live video to see where it is going
- again totally interactive, just not using local media at the user=E2=80= =99s end (although we do use the
motion sensors to give a steering wheel feel) - latency here causes crashes= !

A third one is baby cams, where again the video feed is one-way but you=E2= =80=99d really like to keep the media on the home wifi
if possible for cost (and privacy) reasons.

In all these I=E2=80=99ll have to introduce an otherwise needless GUM reque= st to get the network behaviour I want.

Perhaps I should present some of these non-call based usecases at a future = F2F so that folks get a sense of the possibilities.

Tim.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--94eb2c0ddc0cae77860569b696cb-- From nobody Fri Apr 13 01:23:47 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 249881274D2 for ; Fri, 13 Apr 2018 01:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523607821; bh=a97n4shaxkM+l+DeqbeHbgz8bndYSMBed4HCIQ9RH0U=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=LthwIAysd6CxVT3m1gzLfXad1e/bBgrOIFEKn26A/9cq/j8DkKqC+rnoRXoju3l6b osVeg9ICTFdQbNK1N+IGghB9nGwAGU3WBHA5pjCgZiI+u/tHz89OeDJUzYTkJYVQ32 FqEU3nHnlIsmWvwzhiA062iGQ+c1ccmxbZt5oR3c= X-Mailbox-Line: From balwant.bisht@gmail.com Fri Apr 13 01:23:41 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E14A7124234; Fri, 13 Apr 2018 01:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523607820; bh=a97n4shaxkM+l+DeqbeHbgz8bndYSMBed4HCIQ9RH0U=; h=In-Reply-To:References:From:Date:Subject:To:Cc:Cc; b=m1+JLB+e4jBK4Fibw2Fz2fk3hZWGDvwnqwhg6YjP2oaE2+gkrlBckhtIMwGkUu5/i ZRbvJDxhc/+t1cIIBWjOnfeg8kwk4Ggj4n4CXP5tMQSbGIiw7fWPPJ/t/+eVGI1g1D 6J9+tpUiX0N7AhaBgzrX4WcidzOzB9oAA+oXm5LQ= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7844126C2F for ; Fri, 13 Apr 2018 01:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8eI5dy18lZ0n for ; Fri, 13 Apr 2018 01:23:38 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B4C124234 for ; Fri, 13 Apr 2018 01:23:38 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id o23so6059989wmf.0 for ; Fri, 13 Apr 2018 01:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a97n4shaxkM+l+DeqbeHbgz8bndYSMBed4HCIQ9RH0U=; b=sFZSj4jQxZlx51CXirzMqNbnNC/62ch2/igOwCOUHxcfMG3t/fqZ3ZstOWJQffyQhb JXW/J77QgWzAvSUitxor4Lxafs7jTN4sVP0qQtkWmjzykCiuCPf7nUjpfgGw9uFHcIks amFtnKoq5epSHlxyO6kyjcuhcmp5ftrre7r1AifnSMecMZ9FBBq9mQE7RoKIJ9DlvJJb xDQyJ5/kvHZm6gp0/9wwHRTuJQqO2+sWsAwXoa/tTfd6g5/byhrRoUAHfs1ovfkh7UeA hR9aGTE7v4ffNRPoNhJiKpfF03LjvfaNfoQH92hIqxZDMS97CTQH8cPOh7h7QkbfmNej /OXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a97n4shaxkM+l+DeqbeHbgz8bndYSMBed4HCIQ9RH0U=; b=RGDEEYCPLwu+YbHZWn/5jgmZrLMM5OZ3PmWfks1P7snbN3+mKoig/M8mCFA0twlfRW grnYEz03MqBmCJEOVjsXusGvXp628xWb4GYo7GFSDivtkNPXeHPfHl/gDfIId0tyl7bV QMebjkFacKXag75oOEF8JndOUOl/Jp3lENVSg22oLfqMPL4HxU7xQJOi4Mh683BvcSW6 qTMe3NEkbOcFKyZExmH8S+qNjtbQ2MReLKu5omTtOwNrQ7xjn/ccnhcwGJ0gvH2azarG FFzN6yC+e9HfJWva24K0czaHwazmwBPEuv6CUjt8lTOcHl53WCJmW8P/WwiN3nhM/CVY 6NQw== X-Gm-Message-State: ALQs6tDk0RI4g2ccZ63OChezvmS096LVYePFmJxojN7O3C5BXt00KhgG 7CvYTsnrT4ZAl+UjDk0IUjFWdxNLMS7ZuM/gfho= X-Google-Smtp-Source: AIpwx481u/A+S4yeBJNZKCZuUWwAPnE0KU9MwkfuLgYxq6EjoDaHzKoM+CxfiinvG1NUAOoVvzuqE/EGFNapwtGn/SA= X-Received: by 10.80.170.29 with SMTP id o29mr18687465edc.74.1523607816532; Fri, 13 Apr 2018 01:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.184.161 with HTTP; Fri, 13 Apr 2018 01:23:16 -0700 (PDT) In-Reply-To: <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> From: Balwant Bisht Date: Fri, 13 Apr 2018 13:53:16 +0530 Message-ID: To: westhawk Content-Type: multipart/alternative; boundary="94eb2c0ddc0cae77860569b696cb" Cc: Justin Uberti Cc: RTCWeb IETF Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 08:23:41 -0000 --94eb2c0ddc0cae77860569b696cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also what will happen when user have disabled camera & microphone on his system, don't have any or G Suite Admin have disabled devices on Chromebook and user just want to see a live event (webinar, baby cam etc). Regards Balwant Bisht On Fri, Apr 13, 2018 at 12:29 PM, westhawk wrote: > > > > On 13 Apr 2018, at 02:22, Justin Uberti ietf.org> wrote: > > > > Being non-interactive, it's not clear that those cases require Mode 1 > though; they should work well even in Mode 2. I also don't think that > suggesting "more appropriate means" is useful when we as a WG haven't bee= n > able to come up with any. > > Whoa there! Non interactive, that=E2=80=99s a big step from non-conversat= ional ! > So one current use-case is adjusting room lights over the data channel. > You can literally see latency - an unnecessary cloud round-trip is entire= ly > visible. > > Another is driving a droid over the datachannel using it=E2=80=99s camera= to feed > live video to see where it is going > - again totally interactive, just not using local media at the user=E2=80= =99s end > (although we do use the > motion sensors to give a steering wheel feel) - latency here causes > crashes! > > A third one is baby cams, where again the video feed is one-way but you= =E2=80=99d > really like to keep the media on the home wifi > if possible for cost (and privacy) reasons. > > In all these I=E2=80=99ll have to introduce an otherwise needless GUM req= uest to > get the network behaviour I want. > > Perhaps I should present some of these non-call based usecases at a futur= e > F2F so that folks get a sense of the possibilities. > > Tim. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c0ddc0cae77860569b696cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also what will happen when user have disabled camera &= microphone on his system, don't have any or G Suite Admin have disable= d devices on Chromebook and user just want to see a live event (webinar, ba= by cam etc).

= Regards
Balwant Bisht


On Fri, Apr 13, 2018 at 12:29 PM, westhawk <= span dir=3D"ltr"><thp@westhawk.co.uk> wrote:


> On 13 Apr 2018, at 02:22, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wro= te:
>
> Being non-interactive, it's not clear that those cases require Mod= e 1 though; they should work well even in Mode 2. I also don't think th= at suggesting "more appropriate means" is useful when we as a WG = haven't been able to come up with any.

Whoa there! Non interactive, that=E2=80=99s a big step from non-conv= ersational !
So one current use-case is adjusting room lights over the data channel. You= can literally see latency - an unnecessary cloud round-trip is entirely visible.

Another is driving a droid over the datachannel using it=E2=80=99s camera t= o feed live video to see where it is going
- again totally interactive, just not using local media at the user=E2=80= =99s end (although we do use the
motion sensors to give a steering wheel feel) - latency here causes crashes= !

A third one is baby cams, where again the video feed is one-way but you=E2= =80=99d really like to keep the media on the home wifi
if possible for cost (and privacy) reasons.

In all these I=E2=80=99ll have to introduce an otherwise needless GUM reque= st to get the network behaviour I want.

Perhaps I should present some of these non-call based usecases at a future = F2F so that folks get a sense of the possibilities.

Tim.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--94eb2c0ddc0cae77860569b696cb-- From nobody Fri Apr 13 07:14:27 2018 Return-Path: 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 53563120721 for ; Fri, 13 Apr 2018 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dIOrX94U-2Je for ; Fri, 13 Apr 2018 07:14:24 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690351201F2 for ; Fri, 13 Apr 2018 07:14:24 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id u11so8508086wri.12 for ; Fri, 13 Apr 2018 07:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=31f2EvSuKy8Ii1tPy2MEh0ALokAp4HscXcihNM+SmO4=; b=M+oyyjVdvRUZd2L+aRXrEntv+gRo/OWj6Tdv1fjjqZY7egeoRUPRYujAy3vlEcC2em f2V5rBRU9I2hDGFkWgMsa8jXUW1LGr0ia97w0Cmbqtangmr50Cd3W8ulpkDTqIyM0XrO NR6yZ6loOJBa8oZKoMwfuWuic9JXO2g4xdEZZq67BXh4lxMzKpKkvB5UiFqdI0aqhiYS gZmZbhDj3u4aR3NJTvz6KSsn1aHBqwFPe8x7+YbvwTGkODayFr0CSXJZzo8psaehUYKQ EHdHkFduoi4eClZQHpbmDtqo1sVCl7sFlYlONctlUj6nlyu6bFsFNMGsBfQnzjKbK7gz eE7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=31f2EvSuKy8Ii1tPy2MEh0ALokAp4HscXcihNM+SmO4=; b=oBA/+Z7RFSwn8X6U82uF27TunLqcnpBeD4XPwhiRxWxaeP7mzR08sDzUswbm3/hSCT jdOcECFKqEDWoHOdPDIu05x5S8dZ5mzjKV5WtBBQTJS526E8TNG688LTbe9Kg+r85I3Q M8IKiZYnmENK6vGBc6STkxvEkpwN8garmQ7OT48yTOQeZ1HYtkgW2xfpgk34PdndSoJq 9kwBQzj9YLRMpcV//giUFPugUmOPnvFdZnaczFihN+ucwYB/upF4QYOWQFR0dvssQ2bF RHcC0dnfmDRjU36eGBpTZ3wjBMb0N0AUQdiDHdOQCgA8kd1Dg+AVgUc6vnH2pzpQU4vj HTMw== X-Gm-Message-State: ALQs6tBQmVZ2D2Odp+9yfb/Q5anV0Kb0ZwRDDW9DdFaIG8eHMk48PRoG HN0f8xtVlhUgouxqLc7DM1RhxZKQ X-Google-Smtp-Source: AIpwx4/K9aFFUucZB02WF2OsN5/KrvvFC7H+fWfxnj4u+biz/mV6E683efgAbvmhLBJrlSxa4ribjw== X-Received: by 10.80.131.102 with SMTP id 93mr4397819edh.9.1523628862653; Fri, 13 Apr 2018 07:14:22 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:5cda:3e20:eb99:6efc? (p200300CD6F24EB005CDA3E20EB996EFC.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:5cda:3e20:eb99:6efc]) by smtp.gmail.com with ESMTPSA id b8sm3147636edi.14.2018.04.13.07.14.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 07:14:21 -0700 (PDT) To: Michael Tuexen , Taylor Brandstetter Cc: RTCWeb IETF References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> <1683BDE2-6E74-40BD-966B-ED7DFEB58083@lurchi.franken.de> <2302437f-68b9-b68f-ac14-011f4cf4066d@gmail.com> <4FFCC73B-7BFB-4A32-9B13-C4C0F5BA7408@lurchi.franken.de> From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: Date: Fri, 13 Apr 2018 16:14:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <4FFCC73B-7BFB-4A32-9B13-C4C0F5BA7408@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 14:14:26 -0000 On 13.04.2018 08:03, Michael Tuexen wrote: >> On 13. Apr 2018, at 06:28, Taylor Brandstetter wrote: >> >>> FWIW, I don't believe any browser would count as an implementation with >>> limited resources. >> >> If so, it could say "browsers MUST attempt to negotiate 65535 streams, but be prepared for negotiating fewer, e.g. when communicating with a non-WebRTC endpoint with limited resources"? >> >> Or could just add an explanation for the SHOULD; I don't have strong opinions about this. > You can make a text suggestion... I would vote for an explanation of the SHOULD. A suggestion: The number of streams negotiated during SCTP association setup SHOULD be 65535, which is the maximum number of streams that can be negotiated during the association setup. Implementations with limited resources may support less than 65535 streams to mitigate resource exhaustion when many streams are being used in parallel. I hope that is enough of a hint towards browser implementations to read the SHOULD as a MUST. > However, please note that the ID is in the RFC Editor queue. So it is not > just updating an ID. I'm not sure which changes except for the usual AUTH48 changes > can be done anymore. This is all still fairly new to me, so I don't know how to proceed. If the section can't be changed any more, I guess it's not a big deal since we at least have discussed it here and have a rough idea on how to proceed regarding the W3C WebRTC spec. Cheers Lennart From nobody Fri Apr 13 08:37:24 2018 Return-Path: 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 5871012D95F for ; Fri, 13 Apr 2018 08:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 HFPFfjVPAE1i for ; Fri, 13 Apr 2018 08:37:13 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6C4126DD9 for ; Fri, 13 Apr 2018 08:37:10 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id b16so5624000vka.5 for ; Fri, 13 Apr 2018 08:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qg4/Uc1gdxLP+xMOcAgjx1V+Anaq3OLWnuvvBCrCNMk=; b=B2sRetPZs+xt2tK3bs7yL+CKKaAiZqSE1VBxCuxY1asxCRwe4ddGsxgK2IlWdZBsIo LLl/MUH04aQmHr5nJL3bfyB+FqDMOxhCprlrINo4GTurr/Boxm6GgjyUWB3YXaVXFxg+ xxMU6qvKAVUmRJ8iYkNVWoE3bPGshK2oe4UwgHjjGdYEjDZa9/0L+ROh4vX1CaA63fw6 ZIYunH6PjPunz7bvEVHbFhRe3el/dEQ6NRrK+OyYYbEL93Srwci2BSR40cVT0Pl3miqa vB9fMXcFBJwhLJz46rlRK1s9ZucKGZRbqMO/wZCXQrKV5coj7HUqqlDPJZM0h2bYhF28 kICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qg4/Uc1gdxLP+xMOcAgjx1V+Anaq3OLWnuvvBCrCNMk=; b=k4Rd8xr/htMO4cDFRiLEAiQlQqzR7R9A3g9QcfPaSufywZ+VsCZiQkCe6fVxzruAbC TFdr2YTzUTtiNO5DE/i5ZEvzGubWXXQHvP0s2EZYKdUDmO2mrj3omDKkDhhSPOxpL7zl tLyEB1sSlsDpCnDyoi4tZcAaKA9OIjwJkHCpXVSoG/1cG3YcZ4A0HvFml4EpHgNq6Rec APaFq2LCw2kld6EgJVMGqsq9AdiW7vGs8WoZqLFeS6glcOEz8J9x3YiptO6g6e+4uhuz kPrW59eBGeeauauPWJt7e8nrIaCnuhXPqrrLZmKKa9okUoPpfiEJDvyIkvUadoDsePdO N7AA== X-Gm-Message-State: ALQs6tChIUrBj51boxhbHc0hr+q6TH4jrMgZXmYghNaiEukwSpv4IYtF prjZHHNmDccwgd8UE4b9p5WYlTHbH6G49HDszU9qAkUv X-Google-Smtp-Source: AIpwx4+xjt/TTzkTfJltNm/Bs4oWMPHO0WyPwcJVo0SoSXQGwqpqcBx94vtKqc1BmRPjoD6IxmM6qiUcdvtZ//z6qtk= X-Received: by 10.31.157.216 with SMTP id g207mr4034196vke.111.1523633829085; Fri, 13 Apr 2018 08:37:09 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> In-Reply-To: <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> From: Justin Uberti Date: Fri, 13 Apr 2018 15:36:56 +0000 Message-ID: To: Tim Panton Cc: juberti=40google.com@dmarc.ietf.org, RTCWeb IETF Content-Type: multipart/alternative; boundary="001a114276342732670569bca533" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 15:37:23 -0000 --001a114276342732670569bca533 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2018 at 11:59 PM westhawk wrote: > > > > On 13 Apr 2018, at 02:22, Justin Uberti 40google.com@dmarc.ietf.org> wrote: > > > > Being non-interactive, it's not clear that those cases require Mode 1 > though; they should work well even in Mode 2. I also don't think that > suggesting "more appropriate means" is useful when we as a WG haven't bee= n > able to come up with any. > > Whoa there! Non interactive, that=E2=80=99s a big step from non-conversat= ional ! > So one current use-case is adjusting room lights over the data channel. > You can literally see latency - an unnecessary cloud round-trip is entire= ly > visible. > > Another is driving a droid over the datachannel using it=E2=80=99s camera= to feed > live video to see where it is going > - again totally interactive, just not using local media at the user=E2=80= =99s end > (although we do use the > motion sensors to give a steering wheel feel) - latency here causes > crashes! > > A third one is baby cams, where again the video feed is one-way but you= =E2=80=99d > really like to keep the media on the home wifi > if possible for cost (and privacy) reasons. > > In all these I=E2=80=99ll have to introduce an otherwise needless GUM req= uest to > get the network behaviour I want. > > Perhaps I should present some of these non-call based usecases at a futur= e > F2F so that folks get a sense of the possibilities. > The original comment from Lorenzo that I was responding to specifically cited one-way media broadcasts. Regardless, I contend that those cases as well as your scenarios should all work as desired in Mode 2, which allows direct connections. --001a114276342732670569bca533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Apr 12, 2018 at 11:59 PM westhawk <thp@westhawk.co.uk> wrote:
40google.com@dmarc.ietf.or= g> wrote:
>
> Being non-interactive, it's not clear that those cases require Mod= e 1 though; they should work well even in Mode 2. I also don't think th= at suggesting "more appropriate means" is useful when we as a WG = haven't been able to come up with any.

Whoa there! Non interactive, that=E2=80=99s a big step from non-conversatio= nal !
So one current use-case is adjusting room lights over the data channel. You= can literally see latency - an unnecessary cloud round-trip is entirely visible.

Another is driving a droid over the datachannel using it=E2=80=99s camera t= o feed live video to see where it is going
- again totally interactive, just not using local media at the user=E2=80= =99s end (although we do use the
motion sensors to give a steering wheel feel) - latency here causes crashes= !

A third one is baby cams, where again the video feed is one-way but you=E2= =80=99d really like to keep the media on the home wifi
if possible for cost (and privacy) reasons.

In all these I=E2=80=99ll have to introduce an otherwise needless GUM reque= st to get the network behaviour I want.

Perhaps I should present some of these non-call based usecases at a future = F2F so that folks get a sense of the possibilities.
The original comment from Lorenzo that I was responding to spe= cifically cited one-way media broadcasts.=C2=A0

Re= gardless, I contend that those cases as well as your scenarios should all w= ork as desired in Mode 2, which allows direct connections.
--001a114276342732670569bca533-- From nobody Fri Apr 13 08:37:39 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 780301270A7 for ; Fri, 13 Apr 2018 08:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523633844; bh=Qg4/Uc1gdxLP+xMOcAgjx1V+Anaq3OLWnuvvBCrCNMk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:Cc; b=OLR0i0hm0eVEbG2GS096LV4p2aREmyfqVqY6BlDeRkFOGNRXFce8YYUkUP5y4ofwZ RBBxq07Y4DqGKvoqdgnaMasH9o4L+zjfRX+sdWcwsFHvo7NKMrYXbBBYEQVhFZtTd/ oW0eq/qK1DxN7Kv1oPmeProngHVl00qz4KN/PGBc= X-Mailbox-Line: From juberti@google.com Fri Apr 13 08:37:24 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3676D126DD9; Fri, 13 Apr 2018 08:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523633844; bh=Qg4/Uc1gdxLP+xMOcAgjx1V+Anaq3OLWnuvvBCrCNMk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:Cc; b=OLR0i0hm0eVEbG2GS096LV4p2aREmyfqVqY6BlDeRkFOGNRXFce8YYUkUP5y4ofwZ RBBxq07Y4DqGKvoqdgnaMasH9o4L+zjfRX+sdWcwsFHvo7NKMrYXbBBYEQVhFZtTd/ oW0eq/qK1DxN7Kv1oPmeProngHVl00qz4KN/PGBc= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112DF126D05 for ; Fri, 13 Apr 2018 08:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 LAdJOjnoQaij for ; Fri, 13 Apr 2018 08:37:21 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC106126FB3 for ; Fri, 13 Apr 2018 08:37:10 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id n64so5612343vkf.12 for ; Fri, 13 Apr 2018 08:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qg4/Uc1gdxLP+xMOcAgjx1V+Anaq3OLWnuvvBCrCNMk=; b=B2sRetPZs+xt2tK3bs7yL+CKKaAiZqSE1VBxCuxY1asxCRwe4ddGsxgK2IlWdZBsIo LLl/MUH04aQmHr5nJL3bfyB+FqDMOxhCprlrINo4GTurr/Boxm6GgjyUWB3YXaVXFxg+ xxMU6qvKAVUmRJ8iYkNVWoE3bPGshK2oe4UwgHjjGdYEjDZa9/0L+ROh4vX1CaA63fw6 ZIYunH6PjPunz7bvEVHbFhRe3el/dEQ6NRrK+OyYYbEL93Srwci2BSR40cVT0Pl3miqa vB9fMXcFBJwhLJz46rlRK1s9ZucKGZRbqMO/wZCXQrKV5coj7HUqqlDPJZM0h2bYhF28 kICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qg4/Uc1gdxLP+xMOcAgjx1V+Anaq3OLWnuvvBCrCNMk=; b=eB6Wqh/d62qblAHKWQPNgDlXTaVwZrTigfgTZIh/Z34Bg3ksdxWlQDgmTxloAG4iZI JHbineIngb7MweTnKEM1NiOt8Wpd+So+ZKydhl2BdY1BW4pxqtck2H/WYZ+y7pmhVX0F 0uCVZl4kQdsbIc/ab5gb1FGEoj6X2/uoeGh5FTwJTgDhBMg6uZQ7iSgq049L6PI03jPB 4YX/8npdgQ0J2MU6Gp5TgibLhDIY5Sb2ZK++o0cW7uV9YwG1hpT9lLI1Cd9fNMoIJRFh E0oHt22k3OY8xZBMRBmVTBsj7Lys7+qeCNMbD6P2STQtM/7hTL1iiBbWL5FxQyBsixi9 lTnA== X-Gm-Message-State: ALQs6tC3nZjYhK+e81yGM+lKZLH0Gs/7GwIadkLMXYqssv1rtlINJQhl NMbGazdNI4UCZSzi0LJcoQ7aK3q4i/CmnI80xsx9yg== X-Google-Smtp-Source: AIpwx4+xjt/TTzkTfJltNm/Bs4oWMPHO0WyPwcJVo0SoSXQGwqpqcBx94vtKqc1BmRPjoD6IxmM6qiUcdvtZ//z6qtk= X-Received: by 10.31.157.216 with SMTP id g207mr4034196vke.111.1523633829085; Fri, 13 Apr 2018 08:37:09 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> In-Reply-To: <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> From: Justin Uberti Date: Fri, 13 Apr 2018 15:36:56 +0000 Message-ID: To: Tim Panton Content-Type: multipart/alternative; boundary="001a114276342732670569bca533" Cc: juberti@google.com Cc: RTCWeb IETF Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 15:37:25 -0000 --001a114276342732670569bca533 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2018 at 11:59 PM westhawk wrote: > > > > On 13 Apr 2018, at 02:22, Justin Uberti 40google.com@dmarc.ietf.org> wrote: > > > > Being non-interactive, it's not clear that those cases require Mode 1 > though; they should work well even in Mode 2. I also don't think that > suggesting "more appropriate means" is useful when we as a WG haven't bee= n > able to come up with any. > > Whoa there! Non interactive, that=E2=80=99s a big step from non-conversat= ional ! > So one current use-case is adjusting room lights over the data channel. > You can literally see latency - an unnecessary cloud round-trip is entire= ly > visible. > > Another is driving a droid over the datachannel using it=E2=80=99s camera= to feed > live video to see where it is going > - again totally interactive, just not using local media at the user=E2=80= =99s end > (although we do use the > motion sensors to give a steering wheel feel) - latency here causes > crashes! > > A third one is baby cams, where again the video feed is one-way but you= =E2=80=99d > really like to keep the media on the home wifi > if possible for cost (and privacy) reasons. > > In all these I=E2=80=99ll have to introduce an otherwise needless GUM req= uest to > get the network behaviour I want. > > Perhaps I should present some of these non-call based usecases at a futur= e > F2F so that folks get a sense of the possibilities. > The original comment from Lorenzo that I was responding to specifically cited one-way media broadcasts. Regardless, I contend that those cases as well as your scenarios should all work as desired in Mode 2, which allows direct connections. --001a114276342732670569bca533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Apr 12, 2018 at 11:59 PM westhawk <thp@westhawk.co.uk> wrote:
40google.com@dmarc.ietf.or= g> wrote:
>
> Being non-interactive, it's not clear that those cases require Mod= e 1 though; they should work well even in Mode 2. I also don't think th= at suggesting "more appropriate means" is useful when we as a WG = haven't been able to come up with any.

Whoa there! Non interactive, that=E2=80=99s a big step from non-conversatio= nal !
So one current use-case is adjusting room lights over the data channel. You= can literally see latency - an unnecessary cloud round-trip is entirely visible.

Another is driving a droid over the datachannel using it=E2=80=99s camera t= o feed live video to see where it is going
- again totally interactive, just not using local media at the user=E2=80= =99s end (although we do use the
motion sensors to give a steering wheel feel) - latency here causes crashes= !

A third one is baby cams, where again the video feed is one-way but you=E2= =80=99d really like to keep the media on the home wifi
if possible for cost (and privacy) reasons.

In all these I=E2=80=99ll have to introduce an otherwise needless GUM reque= st to get the network behaviour I want.

Perhaps I should present some of these non-call based usecases at a future = F2F so that folks get a sense of the possibilities.
The original comment from Lorenzo that I was responding to spe= cifically cited one-way media broadcasts.=C2=A0

Re= gardless, I contend that those cases as well as your scenarios should all w= ork as desired in Mode 2, which allows direct connections.
--001a114276342732670569bca533-- From nobody Fri Apr 13 09:17:51 2018 Return-Path: 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 2DBF3127333 for ; Fri, 13 Apr 2018 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Br7nvVcATbkP for ; Fri, 13 Apr 2018 09:17:48 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A155D127275 for ; Fri, 13 Apr 2018 09:17:47 -0700 (PDT) Received: from [IPv6:2003:cd:6f00:5e00:64b7:97b8:c253:28cb] (p200300CD6F005E0064B797B8C25328CB.dip0.t-ipconnect.de [IPv6:2003:cd:6f00:5e00:64b7:97b8:c253:28cb]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 5D809721E280C; Fri, 13 Apr 2018 18:17:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Michael Tuexen In-Reply-To: Date: Fri, 13 Apr 2018 18:17:44 +0200 Cc: Taylor Brandstetter , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> <7E12AF68-A247-469D-887E-065FEBD47D66@lurchi.franken.de> <1683BDE2-6E74-40BD-966B-ED7DFEB58083@lurchi.franken.de> <2302437f-68b9-b68f-ac14-011f4cf4066d@gmail.com> <4FFCC73B-7BFB-4A32-9B13-C4C0F5BA7408@lurchi.franken.de> To: Lennart Grahl X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 16:17:50 -0000 > On 13. Apr 2018, at 16:14, Lennart Grahl = wrote: >=20 > On 13.04.2018 08:03, Michael Tuexen wrote: >>> On 13. Apr 2018, at 06:28, Taylor Brandstetter = wrote: >>>=20 >>>> FWIW, I don't believe any browser would count as an implementation = with >>>> limited resources. >>>=20 >>> If so, it could say "browsers MUST attempt to negotiate 65535 = streams, but be prepared for negotiating fewer, e.g. when communicating = with a non-WebRTC endpoint with limited resources"? >>>=20 >>> Or could just add an explanation for the SHOULD; I don't have strong = opinions about this. >> You can make a text suggestion... I would vote for an explanation of = the SHOULD. >=20 > A suggestion: >=20 > The number of streams negotiated during SCTP association setup = SHOULD > be 65535, which is the maximum number of streams that can be > negotiated during the association setup. Implementations with = limited > resources may support less than 65535 streams to mitigate resource > exhaustion when many streams are being used in parallel. I would suggest to use (just changing one may to MAY): The number of streams negotiated during SCTP association setup SHOULD be 65535, which is the maximum number of streams that can be negotiated during the association setup. Implementations with limited resources MAY support less than 65535 streams to mitigate resource exhaustion when many streams are being used in parallel. >=20 > I hope that is enough of a hint towards browser implementations to = read > the SHOULD as a MUST. >=20 >> However, please note that the ID is in the RFC Editor queue. So it is = not >> just updating an ID. I'm not sure which changes except for the usual = AUTH48 changes >> can be done anymore. >=20 > This is all still fairly new to me, so I don't know how to proceed. If > the section can't be changed any more, I guess it's not a big deal = since > we at least have discussed it here and have a rough idea on how to > proceed regarding the W3C WebRTC spec. The document was finished and submitted to the RFC editor in January = 2015. It is stuck there because of MISREFS. I guess one can change things with AD approval, but I don't want to go = through the whole WG LC and IETF LC procedure again for this change (which I = consider a clarification). Best regards Michael >=20 > Cheers > Lennart From nobody Sat Apr 14 12:33:57 2018 Return-Path: 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 5C93F12D7ED for ; Fri, 13 Apr 2018 05:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 75_e9C9mhn5Y for ; Fri, 13 Apr 2018 05:07:05 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5509D1242F5 for ; Fri, 13 Apr 2018 05:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1523621223; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ijw5WuhwTwdfyf9+Zs5LNTOBuD0ezql6RgZDXYsrhAk=; b=RwqnIzke8zowsjX1UTTlUCox2M1R/k3vnll7SqZUlB38bcH3TL/fhtJDjDKSyAXo /ggbNw2iKYplZkm/KLsIs+WuUd2O7SXM/FQUdVRcSHFpC4PUCotdF++ftTm6Xx+w s9a7KZKuo3T/48zdKZ/QRLklt9BWF9Lllyh7KouewKk=; X-AuditID: c1b4fb2d-1f6969c0000073d9-6e-5ad09d67121b Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.CC.29657.76D90DA5; Fri, 13 Apr 2018 14:07:03 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0382.000; Fri, 13 Apr 2018 14:06:53 +0200 From: Christer Holmberg To: Ben Campbell , Peter Saint-Andre CC: Suhas Nandakumar , Adam Roach , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYA= Date: Fri, 13 Apr 2018 12:06:52 +0000 Message-ID: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> In-Reply-To: <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [131.160.50.130] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4B39094A9B29F742988D260CF0620309@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDIsWRmVeSWpSXmKPExsUyM2J7iG763AtRBv3b5C32/F3EbjG/8zS7 xY+1y5kt3l/Qtfh2odZixp+JzBbnd65nspi6/DGLxdp/7ewWz1aeYrTYObeD2YHbY8rvjawe O2fdZfdYsuQnk0ffgS5Wj1k7n7AEsEZx2aSk5mSWpRbp2yVwZWx7/oK9YCl/xfzP/UwNjLN5 uhg5OSQETCQWT5jM3sXIxSEkcIRR4uyp02wQzhJGifMTZjF3MXJwsAlYSHT/0wZpEBHwlpjZ 8hGshlmglVni7YQbbCAJYYECiZ69+1kgigol1u54BFYkItDFKDFl3RSwIhYBVYmz9/8yg9i8 AtYS7Qf+sUJsO8Qu8fr6QVaQBKeAvcTDyS/ZQWxGATGJ76fWMIHYzALiEreezGeCuFtAYsme 88wQtqjEy8f/wHpFBfQkNpy4zQ5ytYSAksTtDU4QrXoSN6ZC3MAMtLf75UZ2CFtbYtnC11D3 CEqcnPmEZQKj+Cwk22YhaZ+FpH0WkvZZSNoXMLKuYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3Z xAiM84NbfuvuYFz92vEQowAHoxIP7+qaC1FCrIllxZW5hxglOJiVRHhvFgCFeFMSK6tSi/Lj i0pzUosPMUpzsCiJ8+qt2hMlJJCeWJKanZpakFoEk2Xi4JRqYKwwXPL3g8CpCMGgkk07o6Ks SvkqZL0+ZNwsvlO3cMWBd0pS5sFXD/RVql27FbO9/+LyTja17COFu0VOm7Et6Shd4vh+SuKM 1E1iRz5t7ko66CLNGaXMffenzOopxzO4whfneJo9DPteKhrm9aPgW2PY9E9+MREpFtnHYoLN NopsZefct7bLV4mlOCPRUIu5qDgRACma4wfvAgAA Archived-At: X-Mailman-Approved-At: Sat, 14 Apr 2018 12:33:54 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 12:07:07 -0000 Hi, >>On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre >>wrote: >>=20 >> On 4/3/18 2:41 PM, Suhas Nandakumar wrote: >>>=20 >>>=20 >>> On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell >> > wrote: >>>=20 >>>=20 >>>=20 >>>> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre >>>> wrote: >>>>=20 >>>> On 4/3/18 12:27 PM, Suhas Nandakumar wrote: >>>>> Just to complete, ice-bis doesn=B9t normatively reference ice-sip-SDP >>>>> draft when it moved to using =B3usages =B3 indirections for signaling >>>>>protocols. >>>>>=20 >>>>>=20 >>>>> Trickle ice can use similar approach and refer to trickle-sip as >>>>>usage >>>>> for trickle. >>>>=20 >>>> It already does. That's why we pulled all the SDP/SIP stuff out of >>>> draft-ietf-ice-trickle. >>>=20 >>> I assume Suhas meant separating the SDP stuff from the SIP stuff. (I >>> also assume he will correct me if I am wrong.) >>>=20 >>>=20 >>> That's right Ben .. I was just thinking minimal localized changes (thus >>> small time to get new draft done) and then asking trickle, trickle-sip >>>to >>> refer to the new one. (work done to refer is much smaller for these >>> drafts that are at the very end of approval journey) >>>=20 >>> I do agree with Adam, no matter what version of the proposal we pick, >>> there is some work that needs to be done and we >>> should do it. >>=20 >> These documents are on the telechat tomorrow. Are we proposing to delay >> consideration by the IESG while we get this mess sorted out? ;-) > >Hi Peter, > >I currently plan to leave it on. We may discuss a way forward on the >telechat. Also, I=B9d like to get feedback on the rest of the draft(s) fro= m >the other ADs sooner than later. Did you discuss this at the telechat? Any other discussions on how to move forward with this? Regards, Christer From nobody Sat Apr 14 12:34:03 2018 Return-Path: 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 90492124BE8; Fri, 13 Apr 2018 07:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 EudqZ1Z56x-b; Fri, 13 Apr 2018 07:56:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09765120721; Fri, 13 Apr 2018 07:56:17 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3DEu4tV048275 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 Apr 2018 09:56:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8BD6D9F6-B063-4141-9B42-5338EDFAFB33"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 13 Apr 2018 09:56:02 -0500 In-Reply-To: Cc: Peter Saint-Andre , Suhas Nandakumar , Adam Roach , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" To: Christer Holmberg References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-Mailman-Approved-At: Sat, 14 Apr 2018 12:33:54 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 14:56:19 -0000 --Apple-Mail=_8BD6D9F6-B063-4141-9B42-5338EDFAFB33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 13, 2018, at 7:06 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >>> On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre >>> wrote: >>>=20 >>> On 4/3/18 2:41 PM, Suhas Nandakumar wrote: >>>>=20 >>>>=20 >>>> On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell >>> > wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre >>>> > wrote: >>>>>=20 >>>>> On 4/3/18 12:27 PM, Suhas Nandakumar wrote: >>>>>> Just to complete, ice-bis doesn=C4=85t normatively reference = ice-sip-SDP >>>>>> draft when it moved to using =C5=82usages =C5=82 indirections for = signaling >>>>>> protocols. >>>>>>=20 >>>>>>=20 >>>>>> Trickle ice can use similar approach and refer to trickle-sip as >>>>>> usage >>>>>> for trickle. >>>>>=20 >>>>> It already does. That's why we pulled all the SDP/SIP stuff out of >>>>> draft-ietf-ice-trickle. >>>>=20 >>>> I assume Suhas meant separating the SDP stuff from the SIP stuff. = (I >>>> also assume he will correct me if I am wrong.) >>>>=20 >>>>=20 >>>> That's right Ben .. I was just thinking minimal localized changes = (thus >>>> small time to get new draft done) and then asking trickle, = trickle-sip >>>> to >>>> refer to the new one. (work done to refer is much smaller for these >>>> drafts that are at the very end of approval journey) >>>>=20 >>>> I do agree with Adam, no matter what version of the proposal we = pick, >>>> there is some work that needs to be done and we >>>> should do it. >>>=20 >>> These documents are on the telechat tomorrow. Are we proposing to = delay >>> consideration by the IESG while we get this mess sorted out? ;-) >>=20 >> Hi Peter, >>=20 >> I currently plan to leave it on. We may discuss a way forward on the >> telechat. Also, I=C4=85d like to get feedback on the rest of the = draft(s) from >> the other ADs sooner than later. >=20 > Did you discuss this at the telechat? >=20 > Any other discussions on how to move forward with this? Yes, Adam and I have been discussing this with the RTCWEB chairs. = We=E2=80=99ve since discovered that this is not the only JSEP normative = reference chain back to SIP. The RTCWEB chairs are currently discussing = whether they can live with that. They may decide to just reference = things as they stand. If their answer involves a request to restructure = anything, I will pull in the authors and MMUSIC/ICE chairs. Thanks! Ben. --Apple-Mail=_8BD6D9F6-B063-4141-9B42-5338EDFAFB33 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrQxQIACgkQgFZKbJXz 1A1ddw//d1NHWF9kYk4y2EeYSz+WOdJnNYexOzBxS1RWzV0hbUOWVxq/D83xG/zA JNOEUHaHNP0tdWfYzS7McTqmzR1Vy+Y/zGytXOj+NMJDNwmMmQnFl1l7IHU1rl1X OcbQjXjBN86cqAldKfVpLZvKDYnx3ZLviwY590dOG1K1ppJGu0VykEljwab73HuH J68AOQWztYqn/M5bRtv8Vnt/gzTVswQS4NSIIVChqbifPqztwDt7vOY/y/nO6wTX MBsbWpR0GvNKAWen19MjZbjTccg6fgP7AcdNDMVyqnm1UvMQVm1so/93Rb/j9aOY 2f35jI4M45g/YHh+IXD8djOFogsmkrVb8T3tBC+KXz+Vz3HY3ha2bR3Oth6yMWuo XRRuvUu4Im62mKGcWCWCFjiYOv40pDqfnnHjHww8ZiGYzQ+65S+CElM2N+pwG+82 CkLB1Zo+x5M+maDOJvbPvREV5kuU9rPF7DkjG6DTCmpVBosbXlcRkfELvzFm2b5z cepdgkoCuJZvYc6lIdOGWz36EQXZ6/1niegZ2dZZWwa8IxD8losz+tZHVa5Gjb7o Oyit9aWLRyJcvtxoVXtiPLKnGzrI41/Nsuhh8aIUGQrX4NTojIweaF6IvkoGnr4b rnKJcFOhePi9pbcnTy3mR5jqNFnCBoOD8FbEIDOuHVeDsY/VgLg= =lJ2X -----END PGP SIGNATURE----- --Apple-Mail=_8BD6D9F6-B063-4141-9B42-5338EDFAFB33-- From nobody Sat Apr 14 12:34:09 2018 Return-Path: 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 AE8E2128896 for ; Fri, 13 Apr 2018 11:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 ymXkWbSsT3Le for ; Fri, 13 Apr 2018 11:29:28 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 7882E127601 for ; Fri, 13 Apr 2018 11:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1523644162; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uvMBGZlR6ODzJqzE+6bYwsSknzkdZJ8HhP2XXUY15rk=; b=X7jb/ME0XCoRnfoVA+bVP5VsJrofidI+mq3Wwnx6R1EQcdplcTkK/Ak21gqdMs8z ER0jeNbv32L8S8oHPMd41NtXD2Godz8Md2W05709dkMoUinvbKQJ8sWzYBK9La6l 8AcopifT/Hci6DOK16mIP2SjCD7PYxUEo5+zhDhcr4E=; X-AuditID: c1b4fb25-5a75a9c00000522b-91-5ad0f702059e Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.D8.21035.207F0DA5; Fri, 13 Apr 2018 20:29:22 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0382.000; Fri, 13 Apr 2018 20:29:08 +0200 From: Christer Holmberg To: Ben Campbell CC: Peter Saint-Andre , Suhas Nandakumar , Adam Roach , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN Date: Fri, 13 Apr 2018 18:29:08 +0000 Message-ID: <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7B683890F38A4D78BEAC02F6F90025D1ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyM2K7ui7T9wtRBlN36Vvs+buI3WJ+52l2 ix9rlzNbvL+ga/HtQq3FjD8TmS3O71zPZDF1+WMWi7X/2tktnq08xWixc24HswO3x5TfG1k9 ds66y+6xZMlPJo++A12sHrN2PmEJYI3isklJzcksSy3St0vgytiyw7ngXANjxZq9h9kaGH/m dzFyckgImEi0v37ICmILCRxhlFjawN7FyAVkL2GU+DrvHZDDwcEmYCHR/U8bpEZEQEniefNW FpAaZoENzBIrW6+BNQsLFEj07N3PAlFUKLF2xyM2kCIRgWmMEv83vgUrYhFQlXi4eSsjiM0r YC9x4M8lVohtyzkkFkxrBktwAiUWPFnDDmIzCohJfD+1hgnEZhYQl7j1ZD4TxNkCEkv2nGeG sEUlXj7+xwpRkyzxrwniHV4BQYmTM5+wTGAUnoWkfRaSsllIymYBPcosYCDxaJ83RIm2xLKF r5khwvoSt69lIgsvYGRfxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYswe3/FbdwXj5jeMh RgEORiUe3ukfL0QJsSaWFVfmHmKU4GBWEuGNvQEU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzvvQ fHOUkEB6YklqdmpqQWoRTJaJg1OqgTF/za1c1adHfM1rV94uuf3IdbnzbK49Dd3a4g/nH5i2 iaFdXvdoRfo+3wfGP64d5tDouStsfjHu5JNrR1/lVJk4RAQK7RA5+G1l3tT0kP+3t5k4qJd0 LTLtXXn9x+ryZPM+tzj+DQ1ussuu//T9yrhtddvDJIVXm5r4Xm+zFD7WFM7+Z6pi1T4lluKM REMt5qLiRADJDvM+1QIAAA== Archived-At: X-Mailman-Approved-At: Sat, 14 Apr 2018 12:33:54 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 18:29:33 -0000 --_000_7B683890F38A4D78BEAC02F6F90025D1ericssoncom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi, In addition, as I mentioned earlier, there are cases where JSEP references = draft-ice-trickle for things and procedures that don=92t exist in draft-ice= -trickle. Instead those references should be to draft-mmusic-trickle. Regards, Christer Sent from my iPhone On 13 Apr 2018, at 17.56, Ben Campbell > wrote: On Apr 13, 2018, at 7:06 AM, Christer Holmberg > wrote: Hi, On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre > wrote: On 4/3/18 2:41 PM, Suhas Nandakumar wrote: On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell > wrote: On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre > wrote: On 4/3/18 12:27 PM, Suhas Nandakumar wrote: Just to complete, ice-bis doesn=B9t normatively reference ice-sip-SDP draft when it moved to using =B3usages =B3 indirections for signaling protocols. Trickle ice can use similar approach and refer to trickle-sip as usage for trickle. It already does. That's why we pulled all the SDP/SIP stuff out of draft-ietf-ice-trickle. I assume Suhas meant separating the SDP stuff from the SIP stuff. (I also assume he will correct me if I am wrong.) That's right Ben .. I was just thinking minimal localized changes (thus small time to get new draft done) and then asking trickle, trickle-sip to refer to the new one. (work done to refer is much smaller for these drafts that are at the very end of approval journey) I do agree with Adam, no matter what version of the proposal we pick, there is some work that needs to be done and we should do it. These documents are on the telechat tomorrow. Are we proposing to delay consideration by the IESG while we get this mess sorted out? ;-) Hi Peter, I currently plan to leave it on. We may discuss a way forward on the telechat. Also, I=B9d like to get feedback on the rest of the draft(s) from the other ADs sooner than later. Did you discuss this at the telechat? Any other discussions on how to move forward with this? Yes, Adam and I have been discussing this with the RTCWEB chairs. We=92ve s= ince discovered that this is not the only JSEP normative reference chain ba= ck to SIP. The RTCWEB chairs are currently discussing whether they can live= with that. They may decide to just reference things as they stand. If thei= r answer involves a request to restructure anything, I will pull in the aut= hors and MMUSIC/ICE chairs. Thanks! Ben. --_000_7B683890F38A4D78BEAC02F6F90025D1ericssoncom_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi,

In addition, as I mentioned earlier, there are cases where JSEP refere= nces draft-ice-trickle for things and procedures that don=92t exist in draf= t-ice-trickle. Instead those references should be to draft-mmusic-trickle.<= /div>

Regards,

Christer 

Sent from my iPhone

On 13 Apr 2018, at 17.56, Ben Campbell <ben@nostrum.com> wrote:



On Apr 13, 2018, at 7:06 AM, Christer Holmb= erg <christer.holmberg= @ericsson.com> wrote:

Hi,

On Apr 4, 2018, at 11:07 AM, Peter Saint-An= dre <stpeter@mozilla.com><= /span>
wrote:

On 4/3/18 2:41 PM, Suhas Nandakumar wrote:<= /span>


On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbe= ll <ben@nostrum.com
<mail= to:ben@nostrum.com>> wrote:



On Apr 3, 2018, at 2:20 PM, Peter Saint-And= re <stpeter@mozilla.com
<= mailto:stpeter@mozilla.com>> wrote:

On 4/3/18 12:27 PM, Suhas Nandakumar wrote:=
Just to complete, ice-bis doesn=B9t normati= vely reference ice-sip-SDP
draft when it moved to using =B3usages =B3 = indirections for signaling
protocols.


Trickle ice can use similar approach and re= fer to trickle-sip as
usage
for trickle.

It already does. That's why we pulled all t= he SDP/SIP stuff out of
draft-ietf-ice-trickle.

 I assume Suhas meant separating the S= DP stuff from the SIP stuff. (I
 also assume he will correct me if I a= m wrong.)


That's right Ben .. I was just thinking min= imal localized changes (thus
small time to get new draft done) and then = asking trickle, trickle-sip
to
refer to the new one. (work done to refer i= s much smaller for these
drafts that are at the very end of approval= journey)

I do agree with Adam, no matter what versio= n of the proposal we pick,
there is some work that needs to be done an= d we
should do it.

These documents are on the telechat tomorro= w. Are we proposing to delay
consideration by the IESG while we get this= mess sorted out? ;-)

Hi Peter,

I currently plan to leave it on. We may dis= cuss a way forward on the
telechat. Also, I=B9d like to get feedback = on the rest of the draft(s) from
the other ADs sooner than later.

Did you discuss this at the telechat?

Any other discussions on how to move forwar= d with this?

Yes, Adam and I have been discussing this with the RTCWEB chairs. We= =92ve since discovered that this is not the only JSEP normative reference c= hain back to SIP. The RTCWEB chairs are currently discussing whether they c= an live with that. They may decide to just reference things as they stand. If their answer involves a request= to restructure anything, I will pull in the authors and MMUSIC/ICE chairs.=

Thanks!

Ben.

--_000_7B683890F38A4D78BEAC02F6F90025D1ericssoncom_-- From nobody Sat Apr 14 12:34:13 2018 Return-Path: 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 D5680127978; Fri, 13 Apr 2018 12:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 GfK14ufvrUby; Fri, 13 Apr 2018 12:56:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1683127AD4; Fri, 13 Apr 2018 12:56:12 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3DJu08a097300 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 Apr 2018 14:56:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_019D8A7C-D803-4A66-9249-3D5C4AE90557"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 13 Apr 2018 14:55:59 -0500 In-Reply-To: <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> Cc: Peter Saint-Andre , Suhas Nandakumar , Adam Roach , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" To: Christer Holmberg References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: X-Mailman-Approved-At: Sat, 14 Apr 2018 12:33:54 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 19:56:15 -0000 --Apple-Mail=_019D8A7C-D803-4A66-9249-3D5C4AE90557 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes. The question is whether to just move the references in JSEP to = point to mmusic-trickle-sip, or do something different. > On Apr 13, 2018, at 1:29 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 > In addition, as I mentioned earlier, there are cases where JSEP = references draft-ice-trickle for things and procedures that don=E2=80=99t = exist in draft-ice-trickle. Instead those references should be to = draft-mmusic-trickle. >=20 > Regards, >=20 > Christer >=20 > Sent from my iPhone >=20 > On 13 Apr 2018, at 17.56, Ben Campbell wrote: >=20 >>=20 >>=20 >>> On Apr 13, 2018, at 7:06 AM, Christer Holmberg = wrote: >>>=20 >>> Hi, >>>=20 >>>>> On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre = >>>>> wrote: >>>>>=20 >>>>> On 4/3/18 2:41 PM, Suhas Nandakumar wrote: >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell >>>>> > wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre = >>>>>> > wrote: >>>>>>>=20 >>>>>>> On 4/3/18 12:27 PM, Suhas Nandakumar wrote: >>>>>>>> Just to complete, ice-bis doesn=C4=85t normatively reference = ice-sip-SDP >>>>>>>> draft when it moved to using =C5=82usages =C5=82 indirections = for signaling >>>>>>>> protocols. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Trickle ice can use similar approach and refer to trickle-sip = as >>>>>>>> usage >>>>>>>> for trickle. >>>>>>>=20 >>>>>>> It already does. That's why we pulled all the SDP/SIP stuff out = of >>>>>>> draft-ietf-ice-trickle. >>>>>>=20 >>>>>> I assume Suhas meant separating the SDP stuff from the SIP = stuff. (I >>>>>> also assume he will correct me if I am wrong.) >>>>>>=20 >>>>>>=20 >>>>>> That's right Ben .. I was just thinking minimal localized changes = (thus >>>>>> small time to get new draft done) and then asking trickle, = trickle-sip >>>>>> to >>>>>> refer to the new one. (work done to refer is much smaller for = these >>>>>> drafts that are at the very end of approval journey) >>>>>>=20 >>>>>> I do agree with Adam, no matter what version of the proposal we = pick, >>>>>> there is some work that needs to be done and we >>>>>> should do it. >>>>>=20 >>>>> These documents are on the telechat tomorrow. Are we proposing to = delay >>>>> consideration by the IESG while we get this mess sorted out? ;-) >>>>=20 >>>> Hi Peter, >>>>=20 >>>> I currently plan to leave it on. We may discuss a way forward on = the >>>> telechat. Also, I=C4=85d like to get feedback on the rest of the = draft(s) from >>>> the other ADs sooner than later. >>>=20 >>> Did you discuss this at the telechat? >>>=20 >>> Any other discussions on how to move forward with this? >>=20 >> Yes, Adam and I have been discussing this with the RTCWEB chairs. = We=E2=80=99ve since discovered that this is not the only JSEP normative = reference chain back to SIP. The RTCWEB chairs are currently discussing = whether they can live with that. They may decide to just reference = things as they stand. If their answer involves a request to restructure = anything, I will pull in the authors and MMUSIC/ICE chairs. >>=20 >> Thanks! >>=20 >> Ben. >>=20 --Apple-Mail=_019D8A7C-D803-4A66-9249-3D5C4AE90557 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrRC08ACgkQgFZKbJXz 1A2hiA/9HWxY+Sx4AS7gQv8QvWVmlnixvhco+MEMklzIjhooTOfm+Ejf0V5QN+bN 20rqSCPgBImwWRfE1Ob8+Vtpdmj9L2WR52zzbNuPAYZuqRt6R+1Hur4a8JmokLzh zeWoJM9pHBFrTAWx2kZVaaLvmDYW2ZL1glTZwydzzckYqX9AZWZanAkwOW51kfSQ 7uiM82WE0fymik9Ngmo9K8nG4mnVPBbxQ2WUJG1Wi5/zvEkXBtmcC4vX3vnvdgLz unLGEXZ6E030GMYAHp2J4D5ADktwg4y+EsMW49gxbuE+pMaBaDQ+eXlg6jWryDl3 JO6rEODqzL3ikiGCPRLkgBiOsc30bKhSjSDynOboAfS+6YudxkP9AVVHLgcBwi3w ILqGvdyb0HbqAtwxoBgNPyYyF37O2T8yAI7RBp56KmIH4lPzxIN5Y+yZx2cJw/Y3 qPWiKODPCrze3hXoHKUSzMAF0q+q2MQHhEymv6FuiylAr53XKlkcKOqroxU5B85G G34NDSa05Z01NMQes+DEPHj5qeaPWUe05r87FRUE1b+GYBP1ZHQIG4l2vkwUFfDs 7Xul8SyFCXI1y6/2iDwBYWbXXeuFrVjdNrR5pkOcnuli0+s9TNA1nTzAgrbrMMhE ks++fZN0ys+oq1/Ogr3Pg43sDcHm3h1HbJTmEVBraRoD6/VACkY= =JgB4 -----END PGP SIGNATURE----- --Apple-Mail=_019D8A7C-D803-4A66-9249-3D5C4AE90557-- From nobody Sun Apr 15 00:23:05 2018 Return-Path: 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 F2A2212751F for ; Sun, 15 Apr 2018 00:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 cw5NjRyYaAKS for ; Sun, 15 Apr 2018 00:23:01 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 2E355126C0F for ; Sun, 15 Apr 2018 00:23:00 -0700 (PDT) Received: (qmail 75467 invoked from network); 15 Apr 2018 07:22:59 -0000 X-APM-Authkey: 255286/0(159927/0) 31 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 15 Apr 2018 07:22:59 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id E51C818A04B3; Sun, 15 Apr 2018 08:22:58 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id maBFJt62cK91; Sun, 15 Apr 2018 08:22:58 +0100 (BST) Received: from [192.168.0.3] (cable-82-119-15-228.cust.telecolumbus.net [82.119.15.228]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 23F9F18A049B; Sun, 15 Apr 2018 08:22:58 +0100 (BST) From: westhawk Message-Id: <251716DB-7292-4D75-8FD9-ABF2182302A1@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_7E54B455-3B2B-4CC5-B564-E76F3B84FF4D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 15 Apr 2018 09:22:56 +0200 In-Reply-To: Cc: Christer Holmberg , "mmusic-chairs@ietf.org" , mmusic WG , "ice@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" To: Ben Campbell References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 07:23:04 -0000 --Apple-Mail=_7E54B455-3B2B-4CC5-B564-E76F3B84FF4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Apr 2018, at 16:56, Ben Campbell wrote: >=20 > Yes, Adam and I have been discussing this with the RTCWEB chairs. = We=E2=80=99ve since discovered that this is not the only JSEP normative = reference chain back to SIP. The RTCWEB chairs are currently discussing = whether they can live with that. They may decide to just reference = things as they stand. If their answer involves a request to restructure = anything, I will pull in the authors and MMUSIC/ICE chairs. >=20 > Thanks! >=20 > Ben. For what it is worth, I=E2=80=99d argue we can live with it. My thinking is that having a reference chain back to SIP in the = documents reflects the reality of RTCWeb 1.0 implementations. The SDP is there because it = was believed that using it would make interop with other (typically SIP based) = systems easier. Much of the actual implementations grew out of SIP heritage codebases. I think it is only reasonable that the documents reflect this reality. T. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_7E54B455-3B2B-4CC5-B564-E76F3B84FF4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 13 Apr 2018, at 16:56, Ben Campbell <ben@nostrum.com> = wrote:

Yes, Adam and I have been discussing this with the RTCWEB = chairs. We=E2=80=99ve since discovered that this is not the only JSEP = normative reference chain back to SIP. The RTCWEB chairs are currently = discussing whether they can live with that. They may decide to just = reference things as they stand. If their answer involves a request to = restructure anything, I will pull in the authors and MMUSIC/ICE = chairs.

Thanks!

Ben.

For what it is worth, I=E2=80=99d argue we can = live with it.
My thinking is that having a reference chain = back to SIP in the documents reflects
the reality of RTCWeb = 1.0 implementations. The SDP is there because it was = believed
that using it would make interop with other = (typically SIP based) systems easier.

Much of the actual implementations grew out of SIP = heritage codebases.

I think it is = only reasonable that the documents reflect this reality.

T.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_7E54B455-3B2B-4CC5-B564-E76F3B84FF4D-- From nobody Sun Apr 15 06:09:40 2018 Return-Path: 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 51A341200FC for ; Sun, 15 Apr 2018 06:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 3vhgWKwLqj9t for ; Sun, 15 Apr 2018 06:09:36 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F971200C5 for ; Sun, 15 Apr 2018 06:09:35 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id r184so7931793vke.11 for ; Sun, 15 Apr 2018 06:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h7NvPbDOLj1JDrKA5FqnZQMYJbYeo8ij7Psq/2m/Ymc=; b=RTV9KBPdHEX2eUm1xcOAeRQIhppUlLxci+76sAS4p25kplvdLtmCnYa5CBui/2Y7kO o1XeMom0JOjIYNInzHN/AKCymyDup0ss+rGqE3EpCXyMT1VYxiimRZg4mVteTX4JkMu/ zzuLy1lLmdJTizFnrQMgd0cVNzJIy+COa4Bosw/eRMZ9kMM60W8+Ba4Wdi54kBxtRVpH HehAxMVRsFpetsSSog9C34jsgpEMWE0xfHTIvZCfp+RySlB4tyFsBDWwLkLRJpOSt7Wh 2VpPxlrODSBrUYVxRHwJVnUXE1YL15JaTF2W13sBEYRRwMH+vrhMTs9rSdPN/mBc1htl ql9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h7NvPbDOLj1JDrKA5FqnZQMYJbYeo8ij7Psq/2m/Ymc=; b=DmH6fymq3UOnqsqFZYwc0h1LoMrMyvxlaD0wP+6TlB4BrFHptjDWtft64gn6V9A/PV lr3xhgtdufThjz6z2gwNMRQq4ViWbf/qiyhrA5I8FaBILjrEa8rVByDbS4FhbkGpIMXW hLXnaz5taskHU2gf3Pbt2Y0sNlQxcLNn7f8wNZrGhIIX3byUVcgeGTsvuXLMCcE0xR0Z LXZIP2Qdz8hAkXx9XC0/I7NSHWDUTwilK8O+9DrvEqDhxFktkALBnWWxlOmXj6TGZ0h3 o/8nW7RlQUHMPq9ezrpejDRRwsoYJTHY/WWFDFrqW0hlmbyPf5onpBlWZBDxG8XNP0oe 1NUA== X-Gm-Message-State: ALQs6tC68n46RPkgpFJOzii2hkb81yeg8xc1xgTTS2DZa8C0DA3Wg57P RKTPvxxeRmIpTSsMgpN+PxJ6KofgS1b7WXtMYaR04ykr X-Google-Smtp-Source: AIpwx49VpbP7SWxLuSqLINMBO4q+MFVnLt+3lW9uJbP6xL3unGMZ7wW5Lh4u8Hro1shYvZXpfVIQZ8o6S3ZhYprsvpQ= X-Received: by 10.31.147.212 with SMTP id v203mr8412435vkd.39.1523797774237; Sun, 15 Apr 2018 06:09:34 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> In-Reply-To: From: Justin Uberti Date: Sun, 15 Apr 2018 13:09:21 +0000 Message-ID: To: Tim Panton Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="001a1140f7020baf100569e2d1a5" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 13:09:38 -0000 --001a1140f7020baf100569e2d1a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti wrote: > > > On Thu, Apr 12, 2018 at 11:59 PM westhawk wrote: > >> >> >> > On 13 Apr 2018, at 02:22, Justin Uberti > 40google.com@dmarc.ietf.org> wrote: >> > >> > Being non-interactive, it's not clear that those cases require Mode 1 >> though; they should work well even in Mode 2. I also don't think that >> suggesting "more appropriate means" is useful when we as a WG haven't be= en >> able to come up with any. >> >> Whoa there! Non interactive, that=E2=80=99s a big step from non-conversa= tional ! >> So one current use-case is adjusting room lights over the data channel. >> You can literally see latency - an unnecessary cloud round-trip is entir= ely >> visible. >> >> Another is driving a droid over the datachannel using it=E2=80=99s camer= a to feed >> live video to see where it is going >> - again totally interactive, just not using local media at the user=E2= =80=99s end >> (although we do use the >> motion sensors to give a steering wheel feel) - latency here causes >> crashes! >> >> A third one is baby cams, where again the video feed is one-way but you= =E2=80=99d >> really like to keep the media on the home wifi >> if possible for cost (and privacy) reasons. >> >> In all these I=E2=80=99ll have to introduce an otherwise needless GUM re= quest to >> get the network behaviour I want. >> >> Perhaps I should present some of these non-call based usecases at a >> future F2F so that folks get a sense of the possibilities. >> > > The original comment from Lorenzo that I was responding to specifically > cited one-way media broadcasts. > > Regardless, I contend that those cases as well as your scenarios should > all work as desired in Mode 2, which allows direct connections. > Now, one might reasonably ask: if this is the case, what's the benefit of Mode 1? Simply stated, Mode 1 allows the client to pick whatever network interface works best, and this provides two key benefits: a) handoff or multipath between interfaces (e.g. wired/wifi or wifi/cell) b) use of non-VPN interfaces when a VPN exists I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or QUIC will already have to solve this, and it's also not clear that this situation actually presents an issue. Therefore, the problem seems to reduce to b), and this may be a much more tractable situation. If a user is using a VPN to access a web application (i.e., the 'default' route that would be chosen by WebRTC is for a VPN adapter), one could imagine the browser asking permission to use non-VPN interfaces. This could still be too complicated for typical users to understand (as I still don't know what the prompt text should say), but the key point here would be that only VPN users (who presumably are somewhat more savvy) would have to see this prompt. Thoughts? If we like this formulation, we could redefine Mode 1 accordingly, and cite the mechanism above as a potential alternative to getUserMedia. --001a1140f7020baf100569e2d1a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Apr 13, 2018 at 8:36 AM Justin Uberti <juberti@google.com> wrote:


= On Thu, Apr 12, 2018 at 11:59 PM westhawk <thp@westhawk.co.uk> wrote:


> On 13 Apr 2018, at 02:22, Justin Uberti <juberti=3D40google.com@dmarc.ietf.or= g> wrote:
>
> Being non-interactive, it's not clear that those cases require Mod= e 1 though; they should work well even in Mode 2. I also don't think th= at suggesting "more appropriate means" is useful when we as a WG = haven't been able to come up with any.

Whoa there! Non interactive, that=E2=80=99s a big step from non-conversatio= nal !
So one current use-case is adjusting room lights over the data channel. You= can literally see latency - an unnecessary cloud round-trip is entirely visible.

Another is driving a droid over the datachannel using it=E2=80=99s camera t= o feed live video to see where it is going
- again totally interactive, just not using local media at the user=E2=80= =99s end (although we do use the
motion sensors to give a steering wheel feel) - latency here causes crashes= !

A third one is baby cams, where again the video feed is one-way but you=E2= =80=99d really like to keep the media on the home wifi
if possible for cost (and privacy) reasons.

In all these I=E2=80=99ll have to introduce an otherwise needless GUM reque= st to get the network behaviour I want.

Perhaps I should present some of these non-call based usecases at a future = F2F so that folks get a sense of the possibilities.
The original comment from Lorenzo that I was responding to spe= cifically cited one-way media broadcasts.=C2=A0

Re= gardless, I contend that those cases as well as your scenarios should all w= ork as desired in Mode 2, which allows direct connections.

Now, one might reasonably ask: if this is= the case, what's the benefit of Mode 1?

Simpl= y stated, Mode 1 allows the client to pick whatever network interface works= best, and this provides two key benefits:
a) handoff or multipat= h between interfaces (e.g. wired/wifi or wifi/cell)
b) use of non= -VPN interfaces when a VPN exists

I imagine that a= ) is not unique to WebRTC, i.e., in-browser MPTCP or QUIC will already have= to solve this, and it's also not clear that this situation actually pr= esents an issue.

Therefore, the problem seems to r= educe to b), and this may be a much more tractable situation. If a user is = using a VPN to access a web application (i.e., the 'default' route = that would be chosen by WebRTC is for a VPN adapter), one could imagine the= browser asking permission to use non-VPN interfaces.=C2=A0

<= /div>
This could still be too complicated for typical users to understa= nd (as I still don't know what the prompt text should say), but the key= point here would be that only VPN users (who presumably are somewhat more = savvy) would have to see this prompt.

Thoughts? If= we like this formulation, we could redefine Mode 1 accordingly, and cite t= he mechanism above as a potential alternative to getUserMedia.
<= /div> --001a1140f7020baf100569e2d1a5-- From nobody Sun Apr 15 07:40:13 2018 Return-Path: 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 4FC311242F5 for ; Sun, 15 Apr 2018 07:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 N1BQ7avoAbEr for ; Sun, 15 Apr 2018 07:40:09 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (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 D268F1200F1 for ; Sun, 15 Apr 2018 07:40:08 -0700 (PDT) Received: (qmail 85261 invoked from network); 15 Apr 2018 14:40:06 -0000 X-APM-Authkey: 255286/0(159927/0) 184 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 15 Apr 2018 14:40:06 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 7592118A04B3; Sun, 15 Apr 2018 15:40:06 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S2TmNqVYC7pY; Sun, 15 Apr 2018 15:40:06 +0100 (BST) Received: from phage-rock.fritz.box (p5B28C899.dip0.t-ipconnect.de [91.40.200.153]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 1D0DD18A01CF; Sun, 15 Apr 2018 15:40:06 +0100 (BST) From: westhawk Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D7D68522-2F83-4896-9F0C-4BBC07FF8396" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 15 Apr 2018 16:40:04 +0200 In-Reply-To: Cc: RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 14:40:12 -0000 --Apple-Mail=_D7D68522-2F83-4896-9F0C-4BBC07FF8396 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Apr 2018, at 15:09, Justin Uberti wrote: >=20 >=20 >=20 > On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti > wrote: >=20 >=20 > On Thu, Apr 12, 2018 at 11:59 PM westhawk > wrote: >=20 >=20 > > On 13 Apr 2018, at 02:22, Justin Uberti = > wrote: > >=20 > > Being non-interactive, it's not clear that those cases require Mode = 1 though; they should work well even in Mode 2. I also don't think that = suggesting "more appropriate means" is useful when we as a WG haven't = been able to come up with any. >=20 > Whoa there! Non interactive, that=E2=80=99s a big step from = non-conversational ! > So one current use-case is adjusting room lights over the data = channel. You can literally see latency - an unnecessary cloud round-trip = is entirely > visible. >=20 > Another is driving a droid over the datachannel using it=E2=80=99s = camera to feed live video to see where it is going=20 > - again totally interactive, just not using local media at the = user=E2=80=99s end (although we do use the=20 > motion sensors to give a steering wheel feel) - latency here causes = crashes! >=20 > A third one is baby cams, where again the video feed is one-way but = you=E2=80=99d really like to keep the media on the home wifi > if possible for cost (and privacy) reasons. >=20 > In all these I=E2=80=99ll have to introduce an otherwise needless GUM = request to get the network behaviour I want.=20 >=20 > Perhaps I should present some of these non-call based usecases at a = future F2F so that folks get a sense of the possibilities. >=20 > The original comment from Lorenzo that I was responding to = specifically cited one-way media broadcasts.=20 >=20 > Regardless, I contend that those cases as well as your scenarios = should all work as desired in Mode 2, which allows direct connections. >=20 > Now, one might reasonably ask: if this is the case, what's the benefit = of Mode 1? >=20 > Simply stated, Mode 1 allows the client to pick whatever network = interface works best, and this provides two key benefits: > a) handoff or multipath between interfaces (e.g. wired/wifi or = wifi/cell) > b) use of non-VPN interfaces when a VPN exists >=20 > I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or = QUIC will already have to solve this, and it's also not clear that this = situation actually presents an issue. I=E2=80=99m not sure I agree - or disagree - yet. Here are a couple of sources of my uncertainty: SCTP has also has multipath/multihome capabilities which ICE is = effectively obscuring in the current setup. Given this is the 1.0 spec, we also have SRTP to worry about which = isn=E2=80=99t capable of multipath (as far as I=E2=80=99m aware).=20 An example of this may be an LTE phone that has a =E2=80=98data bearer = channel=E2=80=99 and a =E2=80=98media bearer channel=E2=80=99 - the = billing routability and QoS behaviour of these two interfaces will be different. I could imagine that a carrier app = might want to use the media bearer for a voice call. (Sorry for my 3GPP = semi-ignorance). >=20 > Therefore, the problem seems to reduce to b), and this may be a much = more tractable situation. If a user is using a VPN to access a web = application (i.e., the 'default' route that would be chosen by WebRTC is = for a VPN adapter), one could imagine the browser asking permission to = use non-VPN interfaces.=20 Is it possible to tell if an interface is a VPN ? I=E2=80=99m not = convinced I know how to reliably distinguish between a VPN and a = multi-bearer LTE config. >=20 > This could still be too complicated for typical users to understand = (as I still don't know what the prompt text should say), but the key = point here would be that only VPN users (who presumably are somewhat = more savvy) would have to see this prompt. >=20 > Thoughts? If we like this formulation, we could redefine Mode 1 = accordingly, and cite the mechanism above as a potential alternative to = getUserMedia. I like this in principle. But I also feel that the prompt would include = the concept of revealing location/service provider. Tim. =20 --Apple-Mail=_D7D68522-2F83-4896-9F0C-4BBC07FF8396 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 15 Apr 2018, at 15:09, Justin Uberti <juberti@google.com> = wrote:



On Fri, Apr 13, 2018 = at 8:36 AM Justin Uberti <juberti@google.com> wrote:


On Thu, Apr 12, 2018 at 11:59 PM westhawk <thp@westhawk.co.uk> wrote:


> On 13 Apr 2018, at 02:22, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
>
> Being non-interactive, it's not clear that those cases require Mode = 1 though; they should work well even in Mode 2. I also don't think that = suggesting "more appropriate means" is useful when we as a WG haven't = been able to come up with any.

Whoa there! Non interactive, that=E2=80=99s a big step from = non-conversational !
So one current use-case is adjusting room lights over the data channel. = You can literally see latency - an unnecessary cloud round-trip is = entirely
visible.

Another is driving a droid over the datachannel using it=E2=80=99s = camera to feed live video to see where it is going
- again totally interactive, just not using local media at the user=E2=80=99= s end (although we do use the
motion sensors to give a steering wheel feel) - latency here causes = crashes!

A third one is baby cams, where again the video feed is one-way but = you=E2=80=99d really like to keep the media on the home wifi
if possible for cost (and privacy) reasons.

In all these I=E2=80=99ll have to introduce an otherwise needless GUM = request to get the network behaviour I want.

Perhaps I should present some of these non-call based usecases at a = future F2F so that folks get a sense of the possibilities.

The original comment from Lorenzo that I was responding to = specifically cited one-way media broadcasts. 

Regardless, I contend = that those cases as well as your scenarios should all work as desired in = Mode 2, which allows direct = connections.

Now, one might reasonably ask: if this = is the case, what's the benefit of Mode 1?

Simply stated, Mode 1 allows the client = to pick whatever network interface works best, and this provides two key = benefits:
a) handoff or multipath between = interfaces (e.g. wired/wifi or wifi/cell)
b) use of = non-VPN interfaces when a VPN exists

I imagine that a) is not unique to = WebRTC, i.e., in-browser MPTCP or QUIC will already have to solve this, = and it's also not clear that this situation actually presents an = issue.

I=E2=80=99m not sure I agree - or disagree - = yet.
Here are a couple of sources of my = uncertainty:

SCTP has also has = multipath/multihome capabilities which ICE is effectively obscuring in = the current setup.
Given this is the 1.0 spec, we also have = SRTP to worry about which isn=E2=80=99t capable of multipath (as far as = I=E2=80=99m aware). 

An example = of this may be an LTE phone that has a =E2=80=98data bearer channel=E2=80=99= and a =E2=80=98media bearer channel=E2=80=99 - the billing routability = and QoS behaviour of these
two interfaces will be different. I = could imagine that a carrier app might want to use the media bearer for = a voice call. (Sorry for my 3GPP  semi-ignorance).


Therefore, the problem seems to reduce = to b), and this may be a much more tractable situation. If a user is = using a VPN to access a web application (i.e., the 'default' route that = would be chosen by WebRTC is for a VPN adapter), one could imagine the = browser asking permission to use non-VPN = interfaces. 

Is it possible to tell if an interface is a VPN ? = I=E2=80=99m not convinced I know how to reliably distinguish between a = VPN and a multi-bearer LTE
config.


This could still be too complicated for = typical users to understand (as I still don't know what the prompt text = should say), but the key point here would be that only VPN users (who = presumably are somewhat more savvy) would have to see this = prompt.

Thoughts? If we like this formulation, we could redefine Mode = 1 accordingly, and cite the mechanism above as a potential alternative = to getUserMedia.
I like this in principle. But I also feel that the = prompt would include the concept of revealing location/service = provider.

Tim.
 

= --Apple-Mail=_D7D68522-2F83-4896-9F0C-4BBC07FF8396-- From nobody Sun Apr 15 08:12:46 2018 Return-Path: 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 8A360127735 for ; Sun, 15 Apr 2018 08:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 2LH30xa3t-Jz for ; Sun, 15 Apr 2018 08:12:42 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C87120454 for ; Sun, 15 Apr 2018 08:12:42 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id b16so8041344vka.5 for ; Sun, 15 Apr 2018 08:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ohzhwhNtoEkDqTBebUy5IwgT6UJdJTeOYXVFw4uaa58=; b=aToniaTaAK9x/snT8WDJB0PRAUkltVRfTmsruItSzzsthJD5EULgxsBiX2uFkWEjw0 oQyCJCGH9CAuTWJTxM5gsUGncczVyFQiiaUyx0lbK1KJzTrEgytPeou5HUCh5wH/THVq 46dVLkqqClFXyUrZ6c3UX0sQRm3g59NAodiXkr7kwLEUHEr4W6qIw5WI/5E2w5dp/Bmi Q+IzfbPamzEiGJfEcGR7XGmu42ejlBFhcvw2ySrUdSjID7M7Fns530v63ZGixrdai5ge CffZztJUxBSTylkXVOGd3OltZ7cuSUEx9pWHS35Iz/oRxdmkWs5d5qaypOPQWLxQ0HVI LEEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ohzhwhNtoEkDqTBebUy5IwgT6UJdJTeOYXVFw4uaa58=; b=oIuCpoEX7TMS4QnUfp8XT7tGIONPX7JuP7h6j3vPcztx2ThI0qthOipFwFTQFlXaTc bnAc/yBE4X0DizlHrkCJ/U8DN6I7k0pu+dvvjGok2bs/n3r83Rz1qrg7OzrB2QhfV2FN hylEg3rIyPwaWluoySp3/AAIwj9RDDdic14zGK+Lgn1SWDcNDTTz/9grwKwwxlmiPDsw Nrhp9wlQ+Pi1EPRE2lq4KBgME25aKQmjJyLM2a04qyETWVSimC9CPRVHf//uCHzgpXa3 FVmRLuNKNMHL6rhZS0BvF1SG5m5DP1itzPFy/v50UveYuJRoCfpTrHbtu3XtpbkK+4iR 01cQ== X-Gm-Message-State: ALQs6tBPaXCkvFWFFOifxJ8jc24qls1x/bK2w8wrtpvIcnUVISAP2irK nFlyF5eJrLXk80eZgDL617D3M2SjN+RmXDYzzKx36g== X-Google-Smtp-Source: AIpwx48ZyMXqINgNBEeouvbCAdDHNMvWOnzJKbwxLQ3iJgyFqPHslD02cPrHhiSlonDkkev8yIbrsnBCRJqQSYIgtNk= X-Received: by 10.31.223.129 with SMTP id w123mr8892022vkg.9.1523805160775; Sun, 15 Apr 2018 08:12:40 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> In-Reply-To: From: Justin Uberti Date: Sun, 15 Apr 2018 15:12:28 +0000 Message-ID: To: Tim Panton Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c07dc905178c40569e489ee" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 15:12:44 -0000 --94eb2c07dc905178c40569e489ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2018 at 7:40 AM westhawk wrote: > > > On 15 Apr 2018, at 15:09, Justin Uberti wrote: > > > > On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti wrote: > >> >> >> On Thu, Apr 12, 2018 at 11:59 PM westhawk wrote: >> >>> >>> >>> > On 13 Apr 2018, at 02:22, Justin Uberti >> 40google.com@dmarc.ietf.org> wrote: >>> > >>> > Being non-interactive, it's not clear that those cases require Mode 1 >>> though; they should work well even in Mode 2. I also don't think that >>> suggesting "more appropriate means" is useful when we as a WG haven't b= een >>> able to come up with any. >>> >>> Whoa there! Non interactive, that=E2=80=99s a big step from non-convers= ational ! >>> So one current use-case is adjusting room lights over the data channel. >>> You can literally see latency - an unnecessary cloud round-trip is enti= rely >>> visible. >>> >>> Another is driving a droid over the datachannel using it=E2=80=99s came= ra to >>> feed live video to see where it is going >>> - again totally interactive, just not using local media at the user=E2= =80=99s >>> end (although we do use the >>> motion sensors to give a steering wheel feel) - latency here causes >>> crashes! >>> >>> A third one is baby cams, where again the video feed is one-way but >>> you=E2=80=99d really like to keep the media on the home wifi >>> if possible for cost (and privacy) reasons. >>> >>> In all these I=E2=80=99ll have to introduce an otherwise needless GUM r= equest to >>> get the network behaviour I want. >>> >>> Perhaps I should present some of these non-call based usecases at a >>> future F2F so that folks get a sense of the possibilities. >>> >> >> The original comment from Lorenzo that I was responding to specifically >> cited one-way media broadcasts. >> >> Regardless, I contend that those cases as well as your scenarios should >> all work as desired in Mode 2, which allows direct connections. >> > > Now, one might reasonably ask: if this is the case, what's the benefit of > Mode 1? > > Simply stated, Mode 1 allows the client to pick whatever network interfac= e > works best, and this provides two key benefits: > a) handoff or multipath between interfaces (e.g. wired/wifi or wifi/cell) > b) use of non-VPN interfaces when a VPN exists > > I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or QUIC > will already have to solve this, and it's also not clear that this > situation actually presents an issue. > > > I=E2=80=99m not sure I agree - or disagree - yet. > Here are a couple of sources of my uncertainty: > > SCTP has also has multipath/multihome capabilities which ICE is > effectively obscuring in the current setup. > Given this is the 1.0 spec, we also have SRTP to worry about which isn=E2= =80=99t > capable of multipath (as far as I=E2=80=99m aware). > SCTP is a non-issue here; as you point out, it's being tunneled over DTLS/ICE, so it's whatever ICE chooses to do (which is the core issue). SRTP similarly follows what ICE does. And ICE, in Mode 1, can use whatever interface it wants; it can choose a different interface for every packet, as long as it has a valid pair on that interface. > > An example of this may be an LTE phone that has a =E2=80=98data bearer ch= annel=E2=80=99 > and a =E2=80=98media bearer channel=E2=80=99 - the billing routability an= d QoS behaviour of > these > two interfaces will be different. I could imagine that a carrier app migh= t > want to use the media bearer for a voice call. (Sorry for my 3GPP > semi-ignorance). > I don't think this is relevant to this discussion; since this isn't surfaced upwards as different interfaces to the OS, any behavior here is the same as you would get in Mode 2 when using the cellular interface. > > > Therefore, the problem seems to reduce to b), and this may be a much more > tractable situation. If a user is using a VPN to access a web application > (i.e., the 'default' route that would be chosen by WebRTC is for a VPN > adapter), one could imagine the browser asking permission to use non-VPN > interfaces. > > > Is it possible to tell if an interface is a VPN ? I=E2=80=99m not convinc= ed I know > how to reliably distinguish between a VPN and a multi-bearer LTE > config. > You can easily tell those apart via OS interface properties. For example, Windows allows one to determine the type of an interface, e.g. physical or tunnel ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa814491(v=3Dvs.85= ).aspx). Now, there are multiple possible types of tunnel, but even just knowing tunnel vs non-tunnel might be sufficient. > > > This could still be too complicated for typical users to understand (as I > still don't know what the prompt text should say), but the key point here > would be that only VPN users (who presumably are somewhat more savvy) wou= ld > have to see this prompt. > > Thoughts? If we like this formulation, we could redefine Mode 1 > accordingly, and cite the mechanism above as a potential alternative to > getUserMedia. > > I like this in principle. But I also feel that the prompt would include > the concept of revealing location/service provider. > That seems entirely reasonable, especially the "service provider" angle, which is more accurate and likely understandable than "location". --94eb2c07dc905178c40569e489ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Apr 15, 2018 at 7:40 AM westhawk <thp@westhawk.co.uk> wrote:


On 15 Apr 2018, at 15:09, Justin Uberti <juberti@google.com>= ; wrote:



On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti <juberti@google.com> wrote:

<= br>
On Thu, Apr 12, 2018 at 11:5= 9 PM westhawk <t= hp@westhawk.co.uk> wrote:


> On 13 Apr 2018, at 02:22, Justin Uberti <juberti=3D40google.com@dmarc.ietf.or= g> wrote:
>
> Being non-interactive, it's not clear that those cases require Mod= e 1 though; they should work well even in Mode 2. I also don't think th= at suggesting "more appropriate means" is useful when we as a WG = haven't been able to come up with any.

Whoa there! Non interactive, that=E2=80=99s a big step from non-conversatio= nal !
So one current use-case is adjusting room lights over the data channel. You= can literally see latency - an unnecessary cloud round-trip is entirely visible.

Another is driving a droid over the datachannel using it=E2=80=99s camera t= o feed live video to see where it is going
- again totally interactive, just not using local media at the user=E2=80= =99s end (although we do use the
motion sensors to give a steering wheel feel) - latency here causes crashes= !

A third one is baby cams, where again the video feed is one-way but you=E2= =80=99d really like to keep the media on the home wifi
if possible for cost (and privacy) reasons.

In all these I=E2=80=99ll have to introduce an otherwise needless GUM reque= st to get the network behaviour I want.

Perhaps I should present some of these non-call based usecases at a future = F2F so that folks get a sense of the possibilities.
The original comment from Lorenzo that I was responding to spe= cifically cited one-way media broadcasts.=C2=A0

Re= gardless, I contend that those cases as well as your scenarios should all w= ork as desired in Mode 2, which allows direct connections.

Now, one might reasonably ask: if this is= the case, what's the benefit of Mode 1?

Simpl= y stated, Mode 1 allows the client to pick whatever network interface works= best, and this provides two key benefits:
a) handoff or multipat= h between interfaces (e.g. wired/wifi or wifi/cell)
b) use of non= -VPN interfaces when a VPN exists

I imagine that a= ) is not unique to WebRTC, i.e., in-browser MPTCP or QUIC will already have= to solve this, and it's also not clear that this situation actually pr= esents an issue.

I= =E2=80=99m not sure I agree - or disagree - yet.
Here are a coupl= e of sources of my uncertainty:

SCTP has also has = multipath/multihome capabilities which ICE is effectively obscuring in the = current setup.
Given this is the 1.0 spec, we also have SRTP to w= orry about which isn=E2=80=99t capable of multipath (as far as I=E2=80=99m = aware).=C2=A0

SCTP is a n= on-issue here; as you point out, it's being tunneled over DTLS/ICE, so = it's whatever ICE chooses to do (which is the core issue). SRTP similar= ly follows what ICE does. And ICE, in Mode 1, can use whatever interface it= wants; it can choose a different interface for every packet, as long as it= has a valid pair on that interface.

An example of this may be an LTE phone that has a =E2=80=98data bearer c= hannel=E2=80=99 and a =E2=80=98media bearer channel=E2=80=99 - the billing = routability and QoS behaviour of these
two interfaces will be dif= ferent. I could imagine that a carrier app might want to use the media bear= er for a voice call. (Sorry for my 3GPP =C2=A0semi-ignorance).
<= /div>

I don't think this is relevant to= this discussion; since this isn't surfaced upwards as different interf= aces to the OS, any behavior here is the same as you would get in Mode 2 wh= en using the cellular interface.=C2=A0

=
=

Therefore, the problem seems to reduce to b), and this = may be a much more tractable situation. If a user is using a VPN to access = a web application (i.e., the 'default' route that would be chosen b= y WebRTC is for a VPN adapter), one could imagine the browser asking permis= sion to use non-VPN interfaces.=C2=A0
<= div>
Is it possible to tell if an interface is a VPN ? I=E2= =80=99m not convinced I know how to reliably distinguish between a VPN and = a multi-bearer LTE
config.
You can easily tell those apart via OS interface properties. Fo= r example, Windows allows one to determine the type of an interface, e.g. p= hysical or tunnel (https://msdn.microsoft.com/en-us/libr= ary/windows/desktop/aa814491(v=3Dvs.85).aspx).=C2=A0Now, there are mult= iple possible types of tunnel, but even just knowing tunnel vs non-tunnel m= ight be sufficient.
=


This could still be too complicated for typical users to understand (as I = still don't know what the prompt text should say), but the key point he= re would be that only VPN users (who presumably are somewhat more savvy) wo= uld have to see this prompt.

Thoughts? If we like = this formulation, we could redefine Mode 1 accordingly, and cite the mechan= ism above as a potential alternative to getUserMedia.
I like this in principle. But I also feel that the promp= t would include the concept of revealing location/service provider.

That seems entirely reasonable, especi= ally the "service provider" angle, which is more accurate and lik= ely understandable than "location".=C2=A0
--94eb2c07dc905178c40569e489ee-- From nobody Sun Apr 15 08:15:04 2018 Return-Path: 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 CB8D91270B4 for ; Sun, 15 Apr 2018 08:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BecPWy1Culhz for ; Sun, 15 Apr 2018 08:15:01 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A98120454 for ; Sun, 15 Apr 2018 08:15:01 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id w3so2693861wrg.2 for ; Sun, 15 Apr 2018 08:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:openpgp:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1+aV2RYPIisdXujPVGhodLkRdxixhdegCNAbGGPWnH8=; b=fON28ylcfeu72iUpfrtA3+Un2pG3mbwEbr7RcvudGsbn0454gBCnO6AxIhfiKZWwDx G8iIBgWWOG4xBj31OmkwTnR6QN6Py/TiQ3FaktLHwusNhXxYp5J6bkLlPWvsKoyDLTbD KebLc9qIWJylfgbbS1CzGiFpegOhQiacFo/KpKWcPp92XVUnXuWDUttLKwAl9e6Ltd4m eMF4sY++dPoaqPvts/wnyePzMkqMF/IBnZLUo0Caq1T5ICTiK6jQVxa0j1wa3ZqkAdqG GKRmIuVqHY0k1WppLXEPQ49+LxpFujtQTjVgO5ub5ZzuEQY9Tf/9bHYu6FeKvbtagan3 YUtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:openpgp:cc:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1+aV2RYPIisdXujPVGhodLkRdxixhdegCNAbGGPWnH8=; b=Q3XsQkUApL1nUOrZ2/OZvlqpqrMJY/kImidyQIZFAoMjo/KRgvIR13r6oibjNmR+rN t52p92eYKm404iScVVVsod0EViMVWruMqkFsB6HxYphfarhxpkDU5FJSYGiAr0SIiceG IAS2Fxi1kdWSZ+wXkh2058pfY9kw0pcXt4d+PxdAPUhKiMmOhtJNOq+UUNW3wQV+IA64 7+UBx/vJQcVSTHO5EzQhl/Sp+hI4bYpQwvngpwd4gZHgPgz3yipaz094CuNvmrAZgsLL SdA97LosNdjItB3t/c9F/AMK2ZkcU1+q/i7s+fynWO4rKLm5cyg8m+hAbis8DNH7lzmh VNQQ== X-Gm-Message-State: ALQs6tBFrtYgkKK+H7N2bBkJ+lJG6euxhEg9LSwayXOAFnVMF2bDdgX0 YjHO+ewZO5Hc5d1BG8dDKQ8= X-Google-Smtp-Source: AIpwx49aHMiuSju7G2Cuk+2J7l44HcoE96ExkjoBJ/3JIFZnaGdKtLG5J7ydZi2/pUGOILdhE4IEVw== X-Received: by 10.223.134.103 with SMTP id 36mr8522314wrw.23.1523805299633; Sun, 15 Apr 2018 08:14:59 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:554d:d828:76bf:3581? (p200300CD6F24EB00554DD82876BF3581.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:554d:d828:76bf:3581]) by smtp.gmail.com with ESMTPSA id q138sm6376823wmd.1.2018.04.15.08.14.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Apr 2018 08:14:59 -0700 (PDT) From: Lennart Grahl To: rtcweb@ietf.org References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> Openpgp: preference=signencrypt Message-ID: Date: Sun, 15 Apr 2018 17:14:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 15:15:04 -0000 On 15.04.2018 15:09, Justin Uberti wrote: > On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti wrote: > >> >> >> On Thu, Apr 12, 2018 at 11:59 PM westhawk wrote: >> >>> >>> >>>> On 13 Apr 2018, at 02:22, Justin Uberti >> 40google.com@dmarc.ietf.org> wrote: >>>> >>>> Being non-interactive, it's not clear that those cases require Mode 1 >>> though; they should work well even in Mode 2. I also don't think that >>> suggesting "more appropriate means" is useful when we as a WG haven't been >>> able to come up with any. >>> >>> Whoa there! Non interactive, that’s a big step from non-conversational ! >>> So one current use-case is adjusting room lights over the data channel. >>> You can literally see latency - an unnecessary cloud round-trip is entirely >>> visible. >>> >>> Another is driving a droid over the datachannel using it’s camera to feed >>> live video to see where it is going >>> - again totally interactive, just not using local media at the user’s end >>> (although we do use the >>> motion sensors to give a steering wheel feel) - latency here causes >>> crashes! >>> >>> A third one is baby cams, where again the video feed is one-way but you’d >>> really like to keep the media on the home wifi >>> if possible for cost (and privacy) reasons. >>> >>> In all these I’ll have to introduce an otherwise needless GUM request to >>> get the network behaviour I want. >>> >>> Perhaps I should present some of these non-call based usecases at a >>> future F2F so that folks get a sense of the possibilities. >>> >> >> The original comment from Lorenzo that I was responding to specifically >> cited one-way media broadcasts. >> >> Regardless, I contend that those cases as well as your scenarios should >> all work as desired in Mode 2, which allows direct connections. >> > > Now, one might reasonably ask: if this is the case, what's the benefit of > Mode 1? > > Simply stated, Mode 1 allows the client to pick whatever network interface > works best, and this provides two key benefits: > a) handoff or multipath between interfaces (e.g. wired/wifi or wifi/cell) > b) use of non-VPN interfaces when a VPN exists > > I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or QUIC > will already have to solve this, and it's also not clear that this > situation actually presents an issue. I have run into some edge cases where not having a) is an issue: 1. Testing data channel implementations over a separate network where delay, packet loss, etc. can be applied without affecting the signalling network or access to the internet. The only solution I was able to come up with was temporarily changing the default route until the peer connection is set up (and I can't use getUserMedia because I don't always control the test scripts). 2. Sitting in the German high speed train (called "ICE" btw. ;)) and using the hotspot (default route) as well as being connected to the smartphone via another interface and using Threema Web to connect to the smartphone app. This is exactly where WebRTC should shine but it doesn't because the default route lead to both devices talking via TURN since network policies in the train prevent the devices from talking to each other directly. And you can imagine how well TURN works in a high speed train, especially with the horrible network coverage in Germany... 3. Tim brought up another example: "So if my phone is acting as a hotspot for my drone, and connecting to 4g. The phone's 4g is the default route for the browser - but I actually want the traffic to go over the wifi interface." I realise these examples are very specific but I would not be surprised if this is something that happens in large corporate networks as well (peers technically being able to talk to each other via a different network but not via the one with the default route). Cheers Lennart > > Therefore, the problem seems to reduce to b), and this may be a much more > tractable situation. If a user is using a VPN to access a web application > (i.e., the 'default' route that would be chosen by WebRTC is for a VPN > adapter), one could imagine the browser asking permission to use non-VPN > interfaces. > > This could still be too complicated for typical users to understand (as I > still don't know what the prompt text should say), but the key point here > would be that only VPN users (who presumably are somewhat more savvy) would > have to see this prompt. > > Thoughts? If we like this formulation, we could redefine Mode 1 > accordingly, and cite the mechanism above as a potential alternative to > getUserMedia. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Sun Apr 15 08:26:10 2018 Return-Path: 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 7FC521270A3 for ; Sun, 15 Apr 2018 08:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 ghszCubqdChr for ; Sun, 15 Apr 2018 08:26:06 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF40120454 for ; Sun, 15 Apr 2018 08:26:06 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id d9so3131281vka.4 for ; Sun, 15 Apr 2018 08:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QnTEMdyaFiJ+fm63AnJ8yWmKK2q/QJwvgdxnPN0DhjM=; b=fwvm1cFWW3NFqO7VTvVSIJganBzmePDFvbjNMeRk12UQpvI9eNuwFU6qder2aX7GLf lP0YSmttV7rLUjEjfXwRCVApx5UWd/PFvPQwoEffWSJuduDaBm74p/NjGkm0x6oXqVrJ 3KHPLOUesL0Lk9y+l12yVXmrE5Cjv1gIHs0Lqnef5NX8PsydodXUQRuA8m/48upTNW2V y9oaLaqpPQcdYkRLiPSbTAANHaHtq67DUIcYkSRDba+QwZpx06A0Tm/QiPHaTjBkqL2u n+SoooPjTH6j32A9GklCB3UuuCILsR7xyyytqzH9PfZUknUafGp54pB53Xa8QEh5YdUa UnFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QnTEMdyaFiJ+fm63AnJ8yWmKK2q/QJwvgdxnPN0DhjM=; b=Qql99NguP6Mq6sJY5JWSpy4MpV8tQU5trROC6sIg5sCr3Ap9LQYwpvKdB90eqPjEDx OzudOL0q6QgnlRdkRSW2ovbXYjiwAa6nEm86Qob3YvmvWjIr5v6ClfDBXZWc9tN1hq+e 1B2Xone06TFljtiqDf8PLVztFpoy6NautGIy29HWinogGFE73kBm1VKPYskwxQ9fqKAn zrz8RJeH2ttANA11QunYhBcq224kXLRN4a4KJFui1XEWmUVWrMg9jdd9BzHLyiYoU5u0 8tFaY2xeMtV9ftKw4CQVQSLdCB/L/PTlDol3+v4Ijhtwxz/K95sqve1S0zjD3SniHQse KvLw== X-Gm-Message-State: ALQs6tCxAmdpZ5Ru6XJM6D75+j5qHhTnqDT5/mK4v4fk+zF70bDehbrk LEQizyEYGV22efvDDrR7/JuF9hZdG0deVzuRvZxb4Q== X-Google-Smtp-Source: AIpwx49djFX1DNzA2U1Tl+pEE/iTlgmyigKuUZNXqSY5VqbEzRlvxUzXHUG4IHDB7t9ZPr+tornUx7Wny9Q15yVZT3M= X-Received: by 10.31.53.8 with SMTP id c8mr8878041vka.71.1523805964768; Sun, 15 Apr 2018 08:26:04 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> In-Reply-To: From: Justin Uberti Date: Sun, 15 Apr 2018 15:25:54 +0000 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="001a11447a143d9ead0569e4b94c" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 15:26:09 -0000 --001a11447a143d9ead0569e4b94c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2018 at 8:15 AM Lennart Grahl wrote: > On 15.04.2018 15:09, Justin Uberti wrote: > > On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti > wrote: > > > >> > >> > >> On Thu, Apr 12, 2018 at 11:59 PM westhawk wrote: > >> > >>> > >>> > >>>> On 13 Apr 2018, at 02:22, Justin Uberti >>> 40google.com@dmarc.ietf.org> wrote: > >>>> > >>>> Being non-interactive, it's not clear that those cases require Mode = 1 > >>> though; they should work well even in Mode 2. I also don't think that > >>> suggesting "more appropriate means" is useful when we as a WG haven't > been > >>> able to come up with any. > >>> > >>> Whoa there! Non interactive, that=E2=80=99s a big step from non-conve= rsational > ! > >>> So one current use-case is adjusting room lights over the data channe= l. > >>> You can literally see latency - an unnecessary cloud round-trip is > entirely > >>> visible. > >>> > >>> Another is driving a droid over the datachannel using it=E2=80=99s ca= mera to > feed > >>> live video to see where it is going > >>> - again totally interactive, just not using local media at the user= =E2=80=99s > end > >>> (although we do use the > >>> motion sensors to give a steering wheel feel) - latency here causes > >>> crashes! > >>> > >>> A third one is baby cams, where again the video feed is one-way but > you=E2=80=99d > >>> really like to keep the media on the home wifi > >>> if possible for cost (and privacy) reasons. > >>> > >>> In all these I=E2=80=99ll have to introduce an otherwise needless GUM= request > to > >>> get the network behaviour I want. > >>> > >>> Perhaps I should present some of these non-call based usecases at a > >>> future F2F so that folks get a sense of the possibilities. > >>> > >> > >> The original comment from Lorenzo that I was responding to specificall= y > >> cited one-way media broadcasts. > >> > >> Regardless, I contend that those cases as well as your scenarios shoul= d > >> all work as desired in Mode 2, which allows direct connections. > >> > > > > Now, one might reasonably ask: if this is the case, what's the benefit = of > > Mode 1? > > > > Simply stated, Mode 1 allows the client to pick whatever network > interface > > works best, and this provides two key benefits: > > a) handoff or multipath between interfaces (e.g. wired/wifi or wifi/cel= l) > > b) use of non-VPN interfaces when a VPN exists > > > > I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or QU= IC > > will already have to solve this, and it's also not clear that this > > situation actually presents an issue. > > I have run into some edge cases where not having a) is an issue: > > 1. Testing data channel implementations over a separate network where > delay, packet loss, etc. can be applied without affecting the signalling > network or access to the internet. The only solution I was able to come > up with was temporarily changing the default route until the peer > connection is set up (and I can't use getUserMedia because I don't > always control the test scripts). > > 2. Sitting in the German high speed train (called "ICE" btw. ;)) and > using the hotspot (default route) as well as being connected to the > smartphone via another interface and using Threema Web to connect to the > smartphone app. This is exactly where WebRTC should shine but it doesn't > because the default route lead to both devices talking via TURN since > network policies in the train prevent the devices from talking to each > other directly. And you can imagine how well TURN works in a high speed > train, especially with the horrible network coverage in Germany... > > 3. Tim brought up another example: "So if my phone is acting as a > hotspot for my drone, and connecting to 4g. The phone's 4g is the > default route for the browser - but I actually want the traffic to go > over the wifi interface." > > I realise these examples are very specific but I would not be surprised > if this is something that happens in large corporate networks as well > (peers technically being able to talk to each other via a different > network but not via the one with the default route). > > Right, I agree these edge cases are reasonable illustrations of the general case - "use another interface if my primary interface is crap". My overall point is that we might be able to consider using multiple non-virtual interfaces as part of Mode 2, or perhaps an in-between "Mode 1.5", since HTTP traffic could conceivably do the same in the near future (via MPTCP or QUIC connection migration ). IOW, a) could be handled separately from this complex "consent" discussion (and the consent discussion would be focused on b)). --001a11447a143d9ead0569e4b94c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Apr 15, 2018 at 8:15 AM Lennart Grahl <lennart.grahl@gmail.com> wrote:
On 15.04.2018 15:09, Justin Uberti wrote:
> On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti <juberti@google.com> wrote:
>
>>
>>
>> On Thu, Apr 12, 2018 at 11:59 PM westhawk <thp@westhawk.co.uk> wrote:
>>
>>>
>>>
>>>> On 13 Apr 2018, at 02:22, Justin Uberti <juberti=3D
>>> 40google.com@dmarc.ietf.org> wrote:
>>>>
>>>> Being non-interactive, it's not clear that those cases= require Mode 1
>>> though; they should work well even in Mode 2. I also don't= think that
>>> suggesting "more appropriate means" is useful when w= e as a WG haven't been
>>> able to come up with any.
>>>
>>> Whoa there! Non interactive, that=E2=80=99s a big step from no= n-conversational !
>>> So one current use-case is adjusting room lights over the data= channel.
>>> You can literally see latency - an unnecessary cloud round-tri= p is entirely
>>> visible.
>>>
>>> Another is driving a droid over the datachannel using it=E2=80= =99s camera to feed
>>> live video to see where it is going
>>> - again totally interactive, just not using local media at the= user=E2=80=99s end
>>> (although we do use the
>>> motion sensors to give a steering wheel feel) - latency here c= auses
>>> crashes!
>>>
>>> A third one is baby cams, where again the video feed is one-wa= y but you=E2=80=99d
>>> really like to keep the media on the home wifi
>>> if possible for cost (and privacy) reasons.
>>>
>>> In all these I=E2=80=99ll have to introduce an otherwise needl= ess GUM request to
>>> get the network behaviour I want.
>>>
>>> Perhaps I should present some of these non-call based usecases= at a
>>> future F2F so that folks get a sense of the possibilities.
>>>
>>
>> The original comment from Lorenzo that I was responding to specifi= cally
>> cited one-way media broadcasts.
>>
>> Regardless, I contend that those cases as well as your scenarios s= hould
>> all work as desired in Mode 2, which allows direct connections. >>
>
> Now, one might reasonably ask: if this is the case, what's the ben= efit of
> Mode 1?
>
> Simply stated, Mode 1 allows the client to pick whatever network inter= face
> works best, and this provides two key benefits:
> a) handoff or multipath between interfaces (e.g. wired/wifi or wifi/ce= ll)
> b) use of non-VPN interfaces when a VPN exists
>
> I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or Q= UIC
> will already have to solve this, and it's also not clear that this=
> situation actually presents an issue.

I have run into some edge cases where not having a) is an issue:

1. Testing data channel implementations over a separate network where
delay, packet loss, etc. can be applied without affecting the signalling network or access to the internet. The only solution I was able to come
up with was temporarily changing the default route until the peer
connection is set up (and I can't use getUserMedia because I don't<= br> always control the test scripts).

2. Sitting in the German high speed train (called "ICE" btw. ;)) = and
using the hotspot (default route) as well as being connected to the
smartphone via another interface and using Threema Web to connect to the smartphone app. This is exactly where WebRTC should shine but it doesn'= t
because the default route lead to both devices talking via TURN since
network policies in the train prevent the devices from talking to each
other directly. And you can imagine how well TURN works in a high speed
train, especially with the horrible network coverage in Germany...

3. Tim brought up another example: "So if my phone is acting as a
hotspot for my drone, and connecting to 4g. The phone's 4g is the
default route for the browser - but I actually want the traffic to go
over the wifi interface."

I realise these examples are very specific but I would not be surprised
if this is something that happens in large corporate networks as well
(peers technically being able to talk to each other via a different
network but not via the one with the default route).


Right, I agree these edge cases are reasonable illustrati= ons of the general case - "use another interface if my primary interfa= ce is crap".=C2=A0

My overall point is that w= e might be able to consider using multiple non-virtual interfaces as part o= f Mode 2, or perhaps an in-between "Mode 1.5", since HTTP traffic= could conceivably do the same in the near future (via MPTCP or QUIC connection migration). IOW, a) could be handled separately fr= om this complex "consent" discussion (and the consent discussion = would be focused on b)).


--001a11447a143d9ead0569e4b94c-- From nobody Sun Apr 15 08:34:56 2018 Return-Path: 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 4647D124B18 for ; Sun, 15 Apr 2018 08:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6Qvv0x4zWNst for ; Sun, 15 Apr 2018 08:34:53 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 F2996120454 for ; Sun, 15 Apr 2018 08:34:52 -0700 (PDT) Received: (qmail 54171 invoked from network); 15 Apr 2018 15:34:51 -0000 X-APM-Authkey: 255286/0(159927/0) 210 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 15 Apr 2018 15:34:51 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 596C218A04B3; Sun, 15 Apr 2018 16:34:51 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CE8LjxqFgRNQ; Sun, 15 Apr 2018 16:34:51 +0100 (BST) Received: from phage-rock.fritz.box (p5B28C899.dip0.t-ipconnect.de [91.40.200.153]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 0C38418A049B; Sun, 15 Apr 2018 16:34:50 +0100 (BST) From: westhawk Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_36D3BFB7-E504-4849-BA40-A692A8059329" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 15 Apr 2018 17:34:49 +0200 In-Reply-To: Cc: RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 15:34:55 -0000 --Apple-Mail=_36D3BFB7-E504-4849-BA40-A692A8059329 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Apr 2018, at 17:12, Justin Uberti wrote: >=20 >=20 > An example of this may be an LTE phone that has a =E2=80=98data bearer = channel=E2=80=99 and a =E2=80=98media bearer channel=E2=80=99 - the = billing routability and QoS behaviour of these > two interfaces will be different. I could imagine that a carrier app = might want to use the media bearer for a voice call. (Sorry for my 3GPP = semi-ignorance). >=20 > I don't think this is relevant to this discussion; since this isn't = surfaced upwards as different interfaces to the OS, any behavior here is = the same as you would get in Mode 2 when using the cellular interface.=20= That=E2=80=99s not the impression I got from this CCC talk = https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/atta= chments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf = One of the slides explicitly shows 2 interfaces surfaced to the ifconfig = in linux busybox.=20 I realise that these slides are a couple of years old, but I doubt VoLTE = has changed much in that time. (I=E2=80=99m still semi-ignorant on 3gpp = ) Tim. --Apple-Mail=_36D3BFB7-E504-4849-BA40-A692A8059329 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 15 Apr 2018, at 17:12, Justin Uberti <juberti@google.com> = wrote:


An = example of this may be an LTE phone that has a =E2=80=98data bearer = channel=E2=80=99 and a =E2=80=98media bearer channel=E2=80=99 - the = billing routability and QoS behaviour of these
two = interfaces will be different. I could imagine that a carrier app might = want to use the media bearer for a voice call. (Sorry for my 3GPP =  semi-ignorance).

I don't think this is relevant to this discussion; = since this isn't surfaced upwards as different interfaces to the OS, any = behavior here is the same as you would get in Mode 2 when using the = cellular interface. 

That=E2=80=99s not the impression I got from = this CCC talk https://events.ccc.de/congress/2015/Fahrplan/system/event_attac= hments/attachments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pd= f

One of = the slides explicitly shows 2 interfaces surfaced to the ifconfig in = linux busybox. 
I realise that these slides = are a couple of years old, but I doubt VoLTE has changed much in that = time. (I=E2=80=99m still semi-ignorant on 3gpp )

Tim.

= --Apple-Mail=_36D3BFB7-E504-4849-BA40-A692A8059329-- From nobody Sun Apr 15 08:36:09 2018 Return-Path: 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 41D6512895E for ; Sun, 15 Apr 2018 08:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 00tMwUwwgf9E for ; Sun, 15 Apr 2018 08:36:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 9A3FA124B18 for ; Sun, 15 Apr 2018 08:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1523806562; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZR9MokGsnAl4K7SPzPqdCCmRtfAQHnv6mNaSef6r350=; b=fy7rD9jx8YQIKgfycYQtDW+8K8KsCgVg41DqEDSBxXapgwKspEKn3k4TWtj0Ype6 pfdSvSWswKFdazV1S2Y5n1VVZdzzg3Ohxk7Le0TZyzYILBIZbH25VkjSIJ0oqnxx u2qZwXlqW5GHXDfOxDrJthf3pRLFmdLp6ZK0JCPY9fU=; X-AuditID: c1b4fb25-1c7ff7000000522b-8e-5ad3716244d6 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 01.EC.21035.26173DA5; Sun, 15 Apr 2018 17:36:02 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0382.000; Sun, 15 Apr 2018 17:36:02 +0200 From: Christer Holmberg To: westhawk , Ben Campbell CC: "mmusic-chairs@ietf.org" , mmusic WG , "ice@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIACphEAgACqduA= Date: Sun, 15 Apr 2018 15:36:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E74697@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <251716DB-7292-4D75-8FD9-ABF2182302A1@westhawk.co.uk> In-Reply-To: <251716DB-7292-4D75-8FD9-ABF2182302A1@westhawk.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.171] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72E74697ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7im5S4eUogzmLjCzmd55mt/ixdjmz xbcLtRYz/kxktji/cz2TxdTlj1ks1v5rZ7dY9/4YiwOHx5IlP5k8Zu18wuJxcdp+pgDmKC6b lNSczLLUIn27BK6MdbMmsRY8yKxo+PeLpYHxQ1oXIyeHhICJxOXWS8xdjFwcQgJHGCUOrt3G AuEsZpR4OecsWxcjBwebgIVE9z9tkAYRAUeJy33zWEFsZoHJTBKvf0qA2MIClRKX7p5jhKip klhz6jfYUBGBeYwSZ+dvYANJsAioSjTMvckEYvMK+Er8nbIXavNDDonOU1vBijgFnCRuzroL VsQoICbx/dQaJoht4hK3nsxngjhbQGLJnvPMELaoxMvH/1ghbCWJEw8bmSHq8yX+3HjBArFM UOLkzCcsExhFZiEZNQtJ2SwkZbOAfmYW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhF i1OLk3LTjYz1Uosyk4uL8/P08lJLNjECo/Pglt+qOxgvv3E8xCjAwajEwzs5+3KUEGtiWXFl 7iFGCQ5mJRHeZYlAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwPzTdHCQmkJ5akZqemFqQWwWSZ ODilGhilXvFNuZP4L+Lx1pVZb/5Pu1S4RbeiM54jVVHojJ2d0Y7UpyErthxpXs9gG1BiVsef kPM6KF5vQXT59GurzLcvixFcc7xa7ier2Eqn5xPk7obXZM25dolTRuN145W/Khtv1j5aL8sv nz1pFoNveHq2WGzmwS3MLzyP/jxX+7r/cMPkTgOzJTxKLMUZiYZazEXFiQCBjDpCygIAAA== Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 15:36:07 -0000 --_000_7594FB04B1934943A5C02806D1A2204B72E74697ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIGZhciBhcyB0aGUgTU1VU0lDIElDRSBhbmQgdHJpY2tsZS1JQ0UgZHJhZnRzIGFy ZSBjb25jZXJuZWQsIGNhbuKAmXQgd2Ugc2ltcGx5IGFkZCBhIHNlbnRlbmNlIHRvIGVhY2ggb2Yg dGhvc2UgZHJhZnRzIHNheWluZyBzb21ldGhpbmcgbGlrZToNCg0K4oCcVGhlIFNJUCBwcm9jZWR1 cmVzIGFuZCByZXF1aXJlbWVudHMgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIGRvIG5vdCBhcHBseSB0 byBzY2VuYXJpb3Mgd2hlcmUgdGhlIFNEUCBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlcyBhcmUgdXNl ZCB3aXRoIG90aGVyIHByb3RvY29scyBhbmQgQVBJcyB0aGFuIFNJUC7igJ0NCg0KUHJvYmxlbSBz b2x2ZWQ/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHdlc3RoYXdrIFttYWlsdG86 dGhwQHdlc3RoYXdrLmNvLnVrXQ0KU2VudDogMTUgQXByaWwgMjAxOCAwOToyMw0KVG86IEJlbiBD YW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KQ2M6IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBtbXVzaWMtY2hhaXJzQGlldGYub3JnOyBtbXVzaWMg V0cgPG1tdXNpY0BpZXRmLm9yZz47IGljZUBpZXRmLm9yZzsgcnRjd2ViQGlldGYub3JnOyBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtbW11c2ljLXRyaWNrbGUtaWNlLXNpcEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFtNTVVTSUNdIEFkYW0gUm9hY2gncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtbW11c2ljLXRyaWNrbGUtaWNlLXNpcC0xNDogKHdpdGggRElTQ1VT UyBhbmQgQ09NTUVOVCkNCg0KDQoNCg0KT24gMTMgQXByIDIwMTgsIGF0IDE2OjU2LCBCZW4gQ2Ft cGJlbGwgPGJlbkBub3N0cnVtLmNvbTxtYWlsdG86YmVuQG5vc3RydW0uY29tPj4gd3JvdGU6DQoN ClllcywgQWRhbSBhbmQgSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGlzIHdpdGggdGhlIFJUQ1dF QiBjaGFpcnMuIFdl4oCZdmUgc2luY2UgZGlzY292ZXJlZCB0aGF0IHRoaXMgaXMgbm90IHRoZSBv bmx5IEpTRVAgbm9ybWF0aXZlIHJlZmVyZW5jZSBjaGFpbiBiYWNrIHRvIFNJUC4gVGhlIFJUQ1dF QiBjaGFpcnMgYXJlIGN1cnJlbnRseSBkaXNjdXNzaW5nIHdoZXRoZXIgdGhleSBjYW4gbGl2ZSB3 aXRoIHRoYXQuIFRoZXkgbWF5IGRlY2lkZSB0byBqdXN0IHJlZmVyZW5jZSB0aGluZ3MgYXMgdGhl eSBzdGFuZC4gSWYgdGhlaXIgYW5zd2VyIGludm9sdmVzIGEgcmVxdWVzdCB0byByZXN0cnVjdHVy ZSBhbnl0aGluZywgSSB3aWxsIHB1bGwgaW4gdGhlIGF1dGhvcnMgYW5kIE1NVVNJQy9JQ0UgY2hh aXJzLg0KDQpUaGFua3MhDQoNCkJlbi4NCg0KRm9yIHdoYXQgaXQgaXMgd29ydGgsIEnigJlkIGFy Z3VlIHdlIGNhbiBsaXZlIHdpdGggaXQuDQpNeSB0aGlua2luZyBpcyB0aGF0IGhhdmluZyBhIHJl ZmVyZW5jZSBjaGFpbiBiYWNrIHRvIFNJUCBpbiB0aGUgZG9jdW1lbnRzIHJlZmxlY3RzDQp0aGUg cmVhbGl0eSBvZiBSVENXZWIgMS4wIGltcGxlbWVudGF0aW9ucy4gVGhlIFNEUCBpcyB0aGVyZSBi ZWNhdXNlIGl0IHdhcyBiZWxpZXZlZA0KdGhhdCB1c2luZyBpdCB3b3VsZCBtYWtlIGludGVyb3Ag d2l0aCBvdGhlciAodHlwaWNhbGx5IFNJUCBiYXNlZCkgc3lzdGVtcyBlYXNpZXIuDQoNCk11Y2gg b2YgdGhlIGFjdHVhbCBpbXBsZW1lbnRhdGlvbnMgZ3JldyBvdXQgb2YgU0lQIGhlcml0YWdlIGNv ZGViYXNlcy4NCg0KSSB0aGluayBpdCBpcyBvbmx5IHJlYXNvbmFibGUgdGhhdCB0aGUgZG9jdW1l bnRzIHJlZmxlY3QgdGhpcyByZWFsaXR5Lg0KDQpULg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_7594FB04B1934943A5C02806D1A2204B72E74697ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXMgZmFy IGFzIHRoZSBNTVVTSUMgSUNFIGFuZCB0cmlja2xlLUlDRSBkcmFmdHMgYXJlIGNvbmNlcm5lZCwg Y2Fu4oCZdCB3ZSBzaW1wbHkgYWRkIGEgc2VudGVuY2UgdG8gZWFjaCBvZiB0aG9zZSBkcmFmdHMg c2F5aW5nIHNvbWV0aGluZw0KIGxpa2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj7igJxUaGUgU0lQIHByb2NlZHVyZXMgYW5kIHJlcXVpcmVtZW50cyBpbiB0aGlzIHNw ZWNpZmljYXRpb24gZG8gbm90IGFwcGx5IHRvIHNjZW5hcmlvcyB3aGVyZSB0aGUgU0RQIG9mZmVy L2Fuc3dlciBwcm9jZWR1cmVzIGFyZSB1c2VkDQogd2l0aCBvdGhlciBwcm90b2NvbHMgYW5kIEFQ SXMgdGhhbiBTSVAu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Q cm9ibGVtIHNvbHZlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiB3ZXN0aGF3ayBbbWFpbHRvOnRocEB3ZXN0aGF3ay5jby51a10NCjxicj4NCjxi PlNlbnQ6PC9iPiAxNSBBcHJpbCAyMDE4IDA5OjIzPGJyPg0KPGI+VG86PC9iPiBCZW4gQ2FtcGJl bGwgJmx0O2JlbkBub3N0cnVtLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IENocmlzdGVyIEhvbG1i ZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7OyBtbXVzaWMtY2hhaXJz QGlldGYub3JnOyBtbXVzaWMgV0cgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs7IGljZUBpZXRmLm9y ZzsgcnRjd2ViQGlldGYub3JnOyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGRyYWZ0 LWlldGYtbW11c2ljLXRyaWNrbGUtaWNlLXNpcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3J0Y3dlYl0gW01NVVNJQ10gQWRhbSBSb2FjaCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0 Zi1tbXVzaWMtdHJpY2tsZS1pY2Utc2lwLTE0OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTMgQXByIDIwMTgs IGF0IDE2OjU2LCBCZW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5j b20iPmJlbkBub3N0cnVtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KWWVz LCBBZGFtIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoaXMgd2l0aCB0aGUgUlRDV0VCIGNo YWlycy4gV2XigJl2ZSBzaW5jZSBkaXNjb3ZlcmVkIHRoYXQgdGhpcyBpcyBub3QgdGhlIG9ubHkg SlNFUCBub3JtYXRpdmUgcmVmZXJlbmNlIGNoYWluIGJhY2sgdG8gU0lQLiBUaGUgUlRDV0VCIGNo YWlycyBhcmUgY3VycmVudGx5IGRpc2N1c3Npbmcgd2hldGhlciB0aGV5IGNhbiBsaXZlIHdpdGgg dGhhdC4gVGhleSBtYXkgZGVjaWRlIHRvIGp1c3QNCiByZWZlcmVuY2UgdGhpbmdzIGFzIHRoZXkg c3RhbmQuIElmIHRoZWlyIGFuc3dlciBpbnZvbHZlcyBhIHJlcXVlc3QgdG8gcmVzdHJ1Y3R1cmUg YW55dGhpbmcsIEkgd2lsbCBwdWxsIGluIHRoZSBhdXRob3JzIGFuZCBNTVVTSUMvSUNFIGNoYWly cy48YnI+DQo8YnI+DQpUaGFua3MhPGJyPg0KPGJyPg0KQmVuLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Rm9yIHdoYXQgaXQgaXMgd29ydGgsIEnigJlkIGFyZ3VlIHdlIGNhbiBsaXZlIHdpdGggaXQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB0aGlu a2luZyBpcyB0aGF0IGhhdmluZyBhIHJlZmVyZW5jZSBjaGFpbiBiYWNrIHRvIFNJUCBpbiB0aGUg ZG9jdW1lbnRzIHJlZmxlY3RzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj50aGUgcmVhbGl0eSBvZiBSVENXZWIgMS4wIGltcGxlbWVudGF0aW9ucy4g VGhlIFNEUCBpcyB0aGVyZSBiZWNhdXNlIGl0IHdhcyBiZWxpZXZlZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdCB1c2luZyBpdCB3b3VsZCBt YWtlIGludGVyb3Agd2l0aCBvdGhlciAodHlwaWNhbGx5IFNJUCBiYXNlZCkgc3lzdGVtcyBlYXNp ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk11Y2ggb2YgdGhlIGFjdHVhbCBpbXBsZW1lbnRhdGlvbnMgZ3JldyBvdXQgb2YgU0lQIGhlcml0 YWdlIGNvZGViYXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB0aGluayBpdCBpcyBvbmx5IHJlYXNvbmFibGUgdGhhdCB0aGUgZG9jdW1l bnRzIHJlZmxlY3QgdGhpcyByZWFsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxi cj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl YiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B72E74697ESESSMB109erics_-- From nobody Sun Apr 15 08:51:23 2018 Return-Path: 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 C741D127876 for ; Sun, 15 Apr 2018 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 zbl66n6qa1KT for ; Sun, 15 Apr 2018 08:51:20 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D805C1270B4 for ; Sun, 15 Apr 2018 08:51:19 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id x204so8057969vkd.7 for ; Sun, 15 Apr 2018 08:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J8iIjZozVkCw+7lBUpLzNxTZ6AxdaY0TASDZ4BQTgz8=; b=cRmMpQV4AisIBQPD+Kn3UAbZezM4xE4I03DRV8wN1oPgj5zcIB9S51a3AW2Tz/Mb4V wiD7Z4n2SFd+iwWChiVi/k8ig7ezZ6w9uv2oaU6iMCRXXLssdCsZVrwvKVJ30+Vkq3oT OyC58oNv81sP8mRyG+qBBGwJGfJXgtgUWaYqNM8uFPfRoZJAtDCCnPd+mbWoh9sYH3ET So5l/8rruadXWxV9g2SCbZsf684Y7MnbA52fc34GlW3NIY/dwvY6GVJf/qv7jHW3VAgb mnm3okTMINNRcamIewTecyORaViAagrMRVGyAHrD7krVZxHjqEwmuXg61XpRcg1/Gnph qn4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J8iIjZozVkCw+7lBUpLzNxTZ6AxdaY0TASDZ4BQTgz8=; b=O+VRVy8xT9neTgclWRhcyzI623fPSdJds+SsSPDuW3rGxCgVnd9KTqN1nrjEDun1eX KbXbzab53OEUNyUO9sMWuAmTe0PbvsWv24REK4Xzn/pcWQaz/FPI3D4UkDr3NWACrbM+ Tu7q5/3mmn3a5AOugKfmOO0NZYH7L1uVkNvKSkpdIKuJEwazRsMm1f0KKHkuk0ii7TqA ZUi4Ech3yhP6TPI4VozkjPtZtYJYIWEaUJCIrXZFrWm0cm+jeNbr/MDpHpwJTdKrFa1G AgQi2cw3Hd4X+GZCywIf3amzVrLqOnPc4Jn5JLjNPRpBzLlBc4WbWUZm3TDZU3c1JHB1 H48Q== X-Gm-Message-State: ALQs6tAmBk+mhp3ow6DNTTOCjzBbyiCO3If9WjdZcfpmqH9EKMTw+0BU RoGv1lYUzjGYF+Q8kgA8eZl3hMCBGrfMkJkh7nR4NA== X-Google-Smtp-Source: AIpwx48J/ZLhW7DeLtdoHW+W2fxWy54AfHQfcRgCO7sXRVnGB8wxcMYEJyd1JKBMHbkjIj5WgIu3qBlmHuzHZLFdbdc= X-Received: by 10.31.252.68 with SMTP id a65mr9354506vki.78.1523807478360; Sun, 15 Apr 2018 08:51:18 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> In-Reply-To: From: Justin Uberti Date: Sun, 15 Apr 2018 15:51:07 +0000 Message-ID: To: Tim Panton Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c14c6cc74d1660569e513b1" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 15:51:22 -0000 --94eb2c14c6cc74d1660569e513b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2018 at 8:34 AM westhawk wrote: > > > On 15 Apr 2018, at 17:12, Justin Uberti wrote: > > >> An example of this may be an LTE phone that has a =E2=80=98data bearer c= hannel=E2=80=99 >> and a =E2=80=98media bearer channel=E2=80=99 - the billing routability a= nd QoS behaviour of >> these >> two interfaces will be different. I could imagine that a carrier app >> might want to use the media bearer for a voice call. (Sorry for my 3GPP >> semi-ignorance). >> > > I don't think this is relevant to this discussion; since this isn't > surfaced upwards as different interfaces to the OS, any behavior here is > the same as you would get in Mode 2 when using the cellular interface. > > > That=E2=80=99s not the impression I got from this CCC talk > https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/att= achments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf > > One of the slides explicitly shows 2 interfaces surfaced to the ifconfig > in linux busybox. > I realise that these slides are a couple of years old, but I doubt VoLTE > has changed much in that time. (I=E2=80=99m still semi-ignorant on 3gpp ) > Yes, I see what you mean. It seems like the bearer is intended to be locked down to VoLTE traffic - but this may not always be happening yet in practice (although this issue was reported to Google and may have been fixed in a recent version of Android). Regardless, I would still contend that selecting a specific bearer for WebRTC traffic is outside of our current remit. --94eb2c14c6cc74d1660569e513b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Apr 15, 2018 at 8:34 AM westhawk <thp@westhawk.co.uk> wrote:

=
On 15 Apr 2018, at 17:12, Justin Uberti = <juberti@google.= com> wrote:

<= div>

An ex= ample of this may be an LTE phone that has a =E2=80=98data bearer channel= =E2=80=99 and a =E2=80=98media bearer channel=E2=80=99 - the billing routab= ility and QoS behaviour of these
two interfaces will be different= . I could imagine that a carrier app might want to use the media bearer for= a voice call. (Sorry for my 3GPP =C2=A0semi-ignorance).
<= /blockquote>

I don't= think this is relevant to this discussion; since this isn't surfaced u= pwards as different interfaces to the OS, any behavior here is the same as = you would get in Mode 2 when using the cellular interface.=C2=A0


One of the slides ex= plicitly shows 2 interfaces surfaced to the ifconfig in linux busybox.=C2= =A0
I realise that these slides are a couple of years old, but I = doubt VoLTE has changed much in that time. (I=E2=80=99m still semi-ignorant= on 3gpp )

Yes, I see what you = mean. It seems like the bearer is intended to be locked down to VoLTE traff= ic - but this may not always be happening yet in practice (although this is= sue was reported to Google and may have been fixed in a recent version of A= ndroid). Regardless, I would still contend that selecting a specific bearer= for WebRTC traffic is outside of our current remit.
--94eb2c14c6cc74d1660569e513b1-- From nobody Mon Apr 16 14:07:07 2018 Return-Path: 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 E908C127076 for ; Mon, 16 Apr 2018 14:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 jWI7NtOnrPmk for ; Mon, 16 Apr 2018 14:07:03 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F006127010 for ; Mon, 16 Apr 2018 14:07:03 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id v205so10382633vkv.13 for ; Mon, 16 Apr 2018 14:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=7R1nbZL1D83zXGcYQkNhYnBz9GKbu4vcLfyl8s1A2zc=; b=wII8WXlkckY944mYEhxk8mE0+If19BA1N1b6wIx+lMM3D5OGW6up7PGGKKT0Jz4xZ+ X5b0cKSHHz7nz/qfLMSkAa41BonZG+571teEXxY/jV2E+jCS5mREYzIxmdsN1W0j16Cm lAf/oInYrPG/QqQp3gfgVnUHsQ63D7LVAvghyNM9PU9ZVWxcLAgIfGglf2ye+KaPZYHX x+ZaxFtZgUZjmuvN+Rigs83bsCOHfHxSxsJQ+GNAx2uR1U35gKj3lA3+Son9OiT17qpN QUqGj+OcNH6TGfkf20Oe5HnDt0M+l114+Rl01BT3b3xGQuc+cDlqPPlqfQ0OFsfC/NRN a2NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=7R1nbZL1D83zXGcYQkNhYnBz9GKbu4vcLfyl8s1A2zc=; b=pkYBRz3oMsYmr3CyKlS3RKLIYWS8Ke81ZZThLYqO619N586KvdnR9VnDmfkbDDSQib BAr77bvAT5INx0iE3TbxPB6NDZtyEc/VAsNA+wPl9jzOOkMSE3bWJxTgebQyFQ/iVxTS Q/AqoZXbLfapfJ8hUlga8OgPjaugeORDp4ielInteHFuZKITahsT+REZMCXzMpzN7ztU lq+OToznZm4JE7r6mK5jsHKb5UbCDzqZFzguJ+uVnK0VdcEQECEb6K0kyb09VDAqDQ/9 2h/UVcPHFvaZyEY2HfJNq388P90pz+9stgRwBF0Z3UN01VMjSynbiB/6HhrephaSejfE KCrA== X-Gm-Message-State: ALQs6tAj42IFHgLeqRfZdMS/EPgJpuyAzvW9LrO0OPQh5Wb+k6ns2k0W laVv84pL3/P1lUdEnkff1CVmOhb9dhGQkwh03vdtlFg+95I= X-Google-Smtp-Source: AIpwx48tZiPSgFDQ1s4yVHBX2pEbsGxO+wMwqVdEQpeDydN8drhbpkqGQlNXiLcFjefM47iG44i6moaOPdOP53Zwb4U= X-Received: by 10.31.157.216 with SMTP id g207mr12314027vke.111.1523912821312; Mon, 16 Apr 2018 14:07:01 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> In-Reply-To: From: Justin Uberti Date: Mon, 16 Apr 2018 21:06:48 +0000 Message-ID: Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="001a1142763462af2f0569fd9acb" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:07:06 -0000 --001a1142763462af2f0569fd9acb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here's a specific and minimal proposal, which is a slight modification of Sean's proposal in https://github.com/juberti/draughts/pull/98/files: *The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively implementations can provide a specific mechanism to obtain user consent where needed, e.g., when a VPN is in use.* Are folks in favor of: a) the text above b) Sean's proposal (without the boldface) c) something else On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti wrote: > > > On Sun, Apr 15, 2018 at 8:34 AM westhawk wrote: > >> >> >> On 15 Apr 2018, at 17:12, Justin Uberti wrote: >> >> >>> An example of this may be an LTE phone that has a =E2=80=98data bearer = channel=E2=80=99 >>> and a =E2=80=98media bearer channel=E2=80=99 - the billing routability = and QoS behaviour of >>> these >>> two interfaces will be different. I could imagine that a carrier app >>> might want to use the media bearer for a voice call. (Sorry for my 3GPP >>> semi-ignorance). >>> >> >> I don't think this is relevant to this discussion; since this isn't >> surfaced upwards as different interfaces to the OS, any behavior here is >> the same as you would get in Mode 2 when using the cellular interface. >> >> >> That=E2=80=99s not the impression I got from this CCC talk >> https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/at= tachments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf >> >> One of the slides explicitly shows 2 interfaces surfaced to the ifconfig >> in linux busybox. >> I realise that these slides are a couple of years old, but I doubt VoLTE >> has changed much in that time. (I=E2=80=99m still semi-ignorant on 3gpp = ) >> > > Yes, I see what you mean. It seems like the bearer is intended to be > locked down to VoLTE traffic - but this may not always be happening yet i= n > practice (although this issue was reported to Google and may have been > fixed in a recent version of Android). Regardless, I would still contend > that selecting a specific bearer for WebRTC traffic is outside of our > current remit. > --001a1142763462af2f0569fd9acb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's a specific and minimal proposal, which is = a slight modification of=C2=A0Sean's proposal in=C2= =A0https://gi= thub.com/juberti/draughts/pull/98/files:

The details of this consent are left to th= e implementation; one potential mechanism is to tie this consent to getUser= Media consent.=C2=A0Alternatively implementations can provide a specific me= chanism to obtain user consent where needed, e.g., when a VPN is in use.=

Are folks in favor of:
a) t= he text above
b) Sean's proposal (without the boldface)
=
c) something else

On Sun,= Apr 15, 2018 at 8:51 AM Justin Uberti <juberti@google.com> wrote:


On Sun, Apr 15, 2018 at 8:34 AM westhaw= k <thp@westhawk.= co.uk> wrote:


On 15 Apr 2018, at 17:12, Justin Uberti <juberti@google.com> wrote:
<= br class=3D"gmail-m_-8489432939340287372m_-3769921059759790766m_46459840867= 78077962Apple-interchange-newline">

An example of this may be an LTE phone that has= a =E2=80=98data bearer channel=E2=80=99 and a =E2=80=98media bearer channe= l=E2=80=99 - the billing routability and QoS behaviour of these
t= wo interfaces will be different. I could imagine that a carrier app might w= ant to use the media bearer for a voice call. (Sorry for my 3GPP =C2=A0semi= -ignorance).

<= div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va= riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start= ;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te= xt-decoration:none">I don't think this is relevant to this discussion; = since this isn't surfaced upwards as different interfaces to the OS, an= y behavior here is the same as you would get in Mode 2 when using the cellu= lar interface.=C2=A0


=
One of the slides explicitly shows 2 interfaces surfaced to the = ifconfig in linux busybox.=C2=A0
I realise that these slides are = a couple of years old, but I doubt VoLTE has changed much in that time. (I= =E2=80=99m still semi-ignorant on 3gpp )

<= /div>
Yes, I see what you mean. It seems like the bearer is intended to= be locked down to VoLTE traffic - but this may not always be happening yet= in practice (although this issue was reported to Google and may have been = fixed in a recent version of Android). Regardless, I would still contend th= at selecting a specific bearer for WebRTC traffic is outside of our current= remit.
--001a1142763462af2f0569fd9acb-- From nobody Mon Apr 16 14:22:59 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE6F12708C for ; Mon, 16 Apr 2018 14:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523913777; bh=FYuDk/Phkn6jn3V6Z0Ua3oUl0rsX1t4FRJiHr73STX8=; h=Subject:Cc:References:From:Date:In-Reply-To:To; b=Y+zdTwoCN35L0uF36YcMTPQxGakJkuZPCc1DJzbLIIz/9vBWEg2yO+yaYPCeg5YB7 3lBAoZiribTyD6n8moTwwDBA2LeBlRVOSTNKlORqStfLih7qjB197phbM8pwj2uTyt hTrouSCILyiZT/+qzFFP6AVavL+bVjzhqM5+UpMA= X-Mailbox-Line: From adam@nostrum.com Mon Apr 16 14:22:57 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1653A124234 for ; Mon, 16 Apr 2018 14:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523913777; bh=FYuDk/Phkn6jn3V6Z0Ua3oUl0rsX1t4FRJiHr73STX8=; h=Subject:Cc:References:From:Date:In-Reply-To:To; b=Y+zdTwoCN35L0uF36YcMTPQxGakJkuZPCc1DJzbLIIz/9vBWEg2yO+yaYPCeg5YB7 3lBAoZiribTyD6n8moTwwDBA2LeBlRVOSTNKlORqStfLih7qjB197phbM8pwj2uTyt hTrouSCILyiZT/+qzFFP6AVavL+bVjzhqM5+UpMA= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E508E12708C for ; Mon, 16 Apr 2018 14:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 m8hKpl6khRDE for ; Mon, 16 Apr 2018 14:22:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0348124234 for ; Mon, 16 Apr 2018 14:22:54 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3GLMrSu018264 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 16 Apr 2018 16:22:54 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local Cc: RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> From: Adam Roach Message-ID: Date: Mon, 16 Apr 2018 16:22:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9E1CD1DC68A16528F470C6CD" Content-Language: en-US To: Justin Uberti Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:22:57 -0000 This is a multi-part message in MIME format. --------------9E1CD1DC68A16528F470C6CD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit [as an individual] I'm good with (a) or (b). I'm not too hot on (c), as I don't want to see this text caught up in another lengthy round of wordsmithing. /a On 4/16/18 4:06 PM, Justin Uberti wrote: > Here's a specific and minimal proposal, which is a slight modification > of Sean's proposal in https://github.com/juberti/draughts/pull/98/files: > > /The details of this consent are left to the implementation; one > potential mechanism is to tie this consent to getUserMedia > consent. Alternatively implementations can provide a specific > mechanism to obtain user consent *where needed, e.g., when a VPN is in > use.*/ > > Are folks in favor of: > a) the text above > b) Sean's proposal (without the boldface) > c) something else > / > / > On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti > wrote: > > > > On Sun, Apr 15, 2018 at 8:34 AM westhawk > wrote: > > > >> On 15 Apr 2018, at 17:12, Justin Uberti > > wrote: >> >> >> An example of this may be an LTE phone that has a ‘data >> bearer channel’ and a ‘media bearer channel’ - the >> billing routability and QoS behaviour of these >> two interfaces will be different. I could imagine that a >> carrier app might want to use the media bearer for a >> voice call. (Sorry for my 3GPP  semi-ignorance). >> >> >> I don't think this is relevant to this discussion; since this >> isn't surfaced upwards as different interfaces to the OS, any >> behavior here is the same as you would get in Mode 2 when >> using the cellular interface. > > That’s not the impression I got from this CCC talk > https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/attachments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf > > One of the slides explicitly shows 2 interfaces surfaced to > the ifconfig in linux busybox. > I realise that these slides are a couple of years old, but I > doubt VoLTE has changed much in that time. (I’m still > semi-ignorant on 3gpp ) > > > Yes, I see what you mean. It seems like the bearer is intended to > be locked down to VoLTE traffic - but this may not always be > happening yet in practice (although this issue was reported to > Google and may have been fixed in a recent version of Android). > Regardless, I would still contend that selecting a specific bearer > for WebRTC traffic is outside of our current remit. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------9E1CD1DC68A16528F470C6CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[as an individual]

I'm good with (a) or (b). I'm not too hot on (c), as I don't want to see this text caught up in another lengthy round of wordsmithing.

/a

On 4/16/18 4:06 PM, Justin Uberti wrote:
Here's a specific and minimal proposal, which is a slight modification of Sean's proposal in https://github.com/juberti/draughts/pull/98/files:

The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively implementations can provide a specific mechanism to obtain user consent where needed, e.g., when a VPN is in use.

Are folks in favor of:
a) the text above
b) Sean's proposal (without the boldface)
c) something else

On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti <juberti@google.com> wrote:


On Sun, Apr 15, 2018 at 8:34 AM westhawk <thp@westhawk.co.uk> wrote:


On 15 Apr 2018, at 17:12, Justin Uberti <juberti@google.com> wrote:


An example of this may be an LTE phone that has a ‘data bearer channel’ and a ‘media bearer channel’ - the billing routability and QoS behaviour of these
two interfaces will be different. I could imagine that a carrier app might want to use the media bearer for a voice call. (Sorry for my 3GPP  semi-ignorance).

I don't think this is relevant to this discussion; since this isn't surfaced upwards as different interfaces to the OS, any behavior here is the same as you would get in Mode 2 when using the cellular interface. 


One of the slides explicitly shows 2 interfaces surfaced to the ifconfig in linux busybox. 
I realise that these slides are a couple of years old, but I doubt VoLTE has changed much in that time. (I’m still semi-ignorant on 3gpp )

Yes, I see what you mean. It seems like the bearer is intended to be locked down to VoLTE traffic - but this may not always be happening yet in practice (although this issue was reported to Google and may have been fixed in a recent version of Android). Regardless, I would still contend that selecting a specific bearer for WebRTC traffic is outside of our current remit.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--------------9E1CD1DC68A16528F470C6CD-- From nobody Mon Apr 16 14:23:05 2018 Return-Path: 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 4C0DC124234 for ; Mon, 16 Apr 2018 14:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 mdHvt8WTQzYC for ; Mon, 16 Apr 2018 14:22:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268B312704A for ; Mon, 16 Apr 2018 14:22:55 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3GLMrSu018264 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 16 Apr 2018 16:22:54 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Justin Uberti Cc: RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> From: Adam Roach Message-ID: Date: Mon, 16 Apr 2018 16:22:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9E1CD1DC68A16528F470C6CD" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:22:58 -0000 This is a multi-part message in MIME format. --------------9E1CD1DC68A16528F470C6CD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit [as an individual] I'm good with (a) or (b). I'm not too hot on (c), as I don't want to see this text caught up in another lengthy round of wordsmithing. /a On 4/16/18 4:06 PM, Justin Uberti wrote: > Here's a specific and minimal proposal, which is a slight modification > of Sean's proposal in https://github.com/juberti/draughts/pull/98/files: > > /The details of this consent are left to the implementation; one > potential mechanism is to tie this consent to getUserMedia > consent. Alternatively implementations can provide a specific > mechanism to obtain user consent *where needed, e.g., when a VPN is in > use.*/ > > Are folks in favor of: > a) the text above > b) Sean's proposal (without the boldface) > c) something else > / > / > On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti > wrote: > > > > On Sun, Apr 15, 2018 at 8:34 AM westhawk > wrote: > > > >> On 15 Apr 2018, at 17:12, Justin Uberti > > wrote: >> >> >> An example of this may be an LTE phone that has a ‘data >> bearer channel’ and a ‘media bearer channel’ - the >> billing routability and QoS behaviour of these >> two interfaces will be different. I could imagine that a >> carrier app might want to use the media bearer for a >> voice call. (Sorry for my 3GPP  semi-ignorance). >> >> >> I don't think this is relevant to this discussion; since this >> isn't surfaced upwards as different interfaces to the OS, any >> behavior here is the same as you would get in Mode 2 when >> using the cellular interface. > > That’s not the impression I got from this CCC talk > https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/attachments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf > > One of the slides explicitly shows 2 interfaces surfaced to > the ifconfig in linux busybox. > I realise that these slides are a couple of years old, but I > doubt VoLTE has changed much in that time. (I’m still > semi-ignorant on 3gpp ) > > > Yes, I see what you mean. It seems like the bearer is intended to > be locked down to VoLTE traffic - but this may not always be > happening yet in practice (although this issue was reported to > Google and may have been fixed in a recent version of Android). > Regardless, I would still contend that selecting a specific bearer > for WebRTC traffic is outside of our current remit. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------9E1CD1DC68A16528F470C6CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[as an individual]

I'm good with (a) or (b). I'm not too hot on (c), as I don't want to see this text caught up in another lengthy round of wordsmithing.

/a

On 4/16/18 4:06 PM, Justin Uberti wrote:
Here's a specific and minimal proposal, which is a slight modification of Sean's proposal in https://github.com/juberti/draughts/pull/98/files:

The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively implementations can provide a specific mechanism to obtain user consent where needed, e.g., when a VPN is in use.

Are folks in favor of:
a) the text above
b) Sean's proposal (without the boldface)
c) something else

On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti <juberti@google.com> wrote:


On Sun, Apr 15, 2018 at 8:34 AM westhawk <thp@westhawk.co.uk> wrote:


On 15 Apr 2018, at 17:12, Justin Uberti <juberti@google.com> wrote:


An example of this may be an LTE phone that has a ‘data bearer channel’ and a ‘media bearer channel’ - the billing routability and QoS behaviour of these
two interfaces will be different. I could imagine that a carrier app might want to use the media bearer for a voice call. (Sorry for my 3GPP  semi-ignorance).

I don't think this is relevant to this discussion; since this isn't surfaced upwards as different interfaces to the OS, any behavior here is the same as you would get in Mode 2 when using the cellular interface. 


One of the slides explicitly shows 2 interfaces surfaced to the ifconfig in linux busybox. 
I realise that these slides are a couple of years old, but I doubt VoLTE has changed much in that time. (I’m still semi-ignorant on 3gpp )

Yes, I see what you mean. It seems like the bearer is intended to be locked down to VoLTE traffic - but this may not always be happening yet in practice (although this issue was reported to Google and may have been fixed in a recent version of Android). Regardless, I would still contend that selecting a specific bearer for WebRTC traffic is outside of our current remit.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--------------9E1CD1DC68A16528F470C6CD-- From nobody Mon Apr 16 14:33:08 2018 Return-Path: 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 B19281270A7 for ; Mon, 16 Apr 2018 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 KQcF5PqYPar6 for ; Mon, 16 Apr 2018 14:33:04 -0700 (PDT) Received: from smtp121.ord1d.emailsrvr.com (smtp121.ord1d.emailsrvr.com [184.106.54.121]) (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 0E5A0124234 for ; Mon, 16 Apr 2018 14:33:04 -0700 (PDT) Received: from smtp16.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 56D7D40084; Mon, 16 Apr 2018 17:33:03 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 02D814007B; Mon, 16 Apr 2018 17:33:02 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-10-155-40-107.cisco.com ([UNAVAILABLE]. [128.107.241.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:25 (trex/5.7.12); Mon, 16 Apr 2018 17:33:03 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Mon, 16 Apr 2018 14:33:05 -0700 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <658F1CF3-AD18-48A4-AAE9-9490DB4F6B87@iii.ca> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> To: Justin Uberti X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:33:07 -0000 I strongly object to the "e.g., when a VPN is in use." This implying = that this is needed when a VPN is in use - that is simply not true. As i = keep pointing out, most VPNs do not have the problem this draft tries to = deal with. I think that what this draft should say is don't use a VPN = to hide your location that fails to hide your location.=20 If we are deciding that the current text does not have consensus and = need to be changed, then I'm glad to engage in that conversation but = right now I am working the assumption that the current text does have = consensus so not much to say.=20 > On Apr 16, 2018, at 2:06 PM, Justin Uberti = wrote: >=20 > Here's a specific and minimal proposal, which is a slight modification = of Sean's proposal in https://github.com/juberti/draughts/pull/98/files: >=20 > The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use. >=20 > Are folks in favor of: > a) the text above > b) Sean's proposal (without the boldface) > c) something else >=20 > On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti = wrote: >=20 >=20 > On Sun, Apr 15, 2018 at 8:34 AM westhawk wrote: >=20 >=20 >> On 15 Apr 2018, at 17:12, Justin Uberti wrote: >>=20 >>=20 >> An example of this may be an LTE phone that has a =E2=80=98data = bearer channel=E2=80=99 and a =E2=80=98media bearer channel=E2=80=99 - = the billing routability and QoS behaviour of these >> two interfaces will be different. I could imagine that a carrier app = might want to use the media bearer for a voice call. (Sorry for my 3GPP = semi-ignorance). >>=20 >> I don't think this is relevant to this discussion; since this isn't = surfaced upwards as different interfaces to the OS, any behavior here is = the same as you would get in Mode 2 when using the cellular interface.=20= >=20 > That=E2=80=99s not the impression I got from this CCC talk = https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/atta= chments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf >=20 > One of the slides explicitly shows 2 interfaces surfaced to the = ifconfig in linux busybox.=20 > I realise that these slides are a couple of years old, but I doubt = VoLTE has changed much in that time. (I=E2=80=99m still semi-ignorant on = 3gpp ) >=20 > Yes, I see what you mean. It seems like the bearer is intended to be = locked down to VoLTE traffic - but this may not always be happening yet = in practice (although this issue was reported to Google and may have = been fixed in a recent version of Android). Regardless, I would still = contend that selecting a specific bearer for WebRTC traffic is outside = of our current remit. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Apr 16 14:33:12 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5753124234 for ; Mon, 16 Apr 2018 14:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523914386; bh=UJTXG1qTTA99/5Cki0LbdtYCVf+BHX0WMtp8w5WwMOc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=N+cYPdsGY9wSyimBe53W/z3KCosys4QXvWDemjK4vEFfysn4EqjWMOWGFPWlJQzZb c4z+qoeYs/DUI6G4AEWuq03Z+fdCFs5YcNXDh6irRlZd6c6R5qoujv73LMd1Q6Dl0H 1xnd1oDG3LfS4z8iq1EQ7zl+6hzgU5ssHKpSBbOM= X-Mailbox-Line: From fluffy@iii.ca Mon Apr 16 14:33:06 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8081D1270A0 for ; Mon, 16 Apr 2018 14:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523914386; bh=UJTXG1qTTA99/5Cki0LbdtYCVf+BHX0WMtp8w5WwMOc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=N+cYPdsGY9wSyimBe53W/z3KCosys4QXvWDemjK4vEFfysn4EqjWMOWGFPWlJQzZb c4z+qoeYs/DUI6G4AEWuq03Z+fdCFs5YcNXDh6irRlZd6c6R5qoujv73LMd1Q6Dl0H 1xnd1oDG3LfS4z8iq1EQ7zl+6hzgU5ssHKpSBbOM= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BE11270A7 for ; Mon, 16 Apr 2018 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nXWXbmalMHhG for ; Mon, 16 Apr 2018 14:33:04 -0700 (PDT) Received: from smtp125.ord1d.emailsrvr.com (smtp125.ord1d.emailsrvr.com [184.106.54.125]) (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 1482E1270A0 for ; Mon, 16 Apr 2018 14:33:04 -0700 (PDT) Received: from smtp16.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 56D7D40084; Mon, 16 Apr 2018 17:33:03 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 02D814007B; Mon, 16 Apr 2018 17:33:02 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-10-155-40-107.cisco.com ([UNAVAILABLE]. [128.107.241.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:25 (trex/5.7.12); Mon, 16 Apr 2018 17:33:03 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Mon, 16 Apr 2018 14:33:05 -0700 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <658F1CF3-AD18-48A4-AAE9-9490DB4F6B87@iii.ca> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> X-Mailer: Apple Mail (2.3124) To: Justin Uberti Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:33:07 -0000 I strongly object to the "e.g., when a VPN is in use." This implying = that this is needed when a VPN is in use - that is simply not true. As i = keep pointing out, most VPNs do not have the problem this draft tries to = deal with. I think that what this draft should say is don't use a VPN = to hide your location that fails to hide your location.=20 If we are deciding that the current text does not have consensus and = need to be changed, then I'm glad to engage in that conversation but = right now I am working the assumption that the current text does have = consensus so not much to say.=20 > On Apr 16, 2018, at 2:06 PM, Justin Uberti = wrote: >=20 > Here's a specific and minimal proposal, which is a slight modification = of Sean's proposal in https://github.com/juberti/draughts/pull/98/files: >=20 > The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use. >=20 > Are folks in favor of: > a) the text above > b) Sean's proposal (without the boldface) > c) something else >=20 > On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti = wrote: >=20 >=20 > On Sun, Apr 15, 2018 at 8:34 AM westhawk wrote: >=20 >=20 >> On 15 Apr 2018, at 17:12, Justin Uberti wrote: >>=20 >>=20 >> An example of this may be an LTE phone that has a =E2=80=98data = bearer channel=E2=80=99 and a =E2=80=98media bearer channel=E2=80=99 - = the billing routability and QoS behaviour of these >> two interfaces will be different. I could imagine that a carrier app = might want to use the media bearer for a voice call. (Sorry for my 3GPP = semi-ignorance). >>=20 >> I don't think this is relevant to this discussion; since this isn't = surfaced upwards as different interfaces to the OS, any behavior here is = the same as you would get in Mode 2 when using the cellular interface.=20= >=20 > That=E2=80=99s not the impression I got from this CCC talk = https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/atta= chments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf >=20 > One of the slides explicitly shows 2 interfaces surfaced to the = ifconfig in linux busybox.=20 > I realise that these slides are a couple of years old, but I doubt = VoLTE has changed much in that time. (I=E2=80=99m still semi-ignorant on = 3gpp ) >=20 > Yes, I see what you mean. It seems like the bearer is intended to be = locked down to VoLTE traffic - but this may not always be happening yet = in practice (although this issue was reported to Google and may have = been fixed in a recent version of Android). Regardless, I would still = contend that selecting a specific bearer for WebRTC traffic is outside = of our current remit. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Apr 16 15:24:41 2018 Return-Path: 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 B5A35129C51 for ; Mon, 16 Apr 2018 15:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 aGcNYaT0aXqd for ; Mon, 16 Apr 2018 15:24:37 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DBD129C6B for ; Mon, 16 Apr 2018 15:24:37 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id bj1-v6so10816127plb.8 for ; Mon, 16 Apr 2018 15:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F588ZyYFdAuMLjJa5MYxHuatGEAXtaEWekIshncOv6E=; b=MmLB/t5rPcV9ZnScWwBD5mSopR65u1cOsELEFoGKYLP+hjBE4clqL/5OdgwFil5Dch cLqFy3d/VNn8ESpDmuXN9cO+V90xRi6WXc4Pa0KUQH5UcXQXrMVHNhn2T38R1zXZCc+h w4fq59G7WEGbKMrGNoUXygqNmZ4FVQw+98Q2I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=F588ZyYFdAuMLjJa5MYxHuatGEAXtaEWekIshncOv6E=; b=QJ9hFae0zxGgARTw4mHaquQPXxVmnISt+TO8SijQDOVwnTwjd1V/Geqfu4dFU/Dwul P8rmmXZf4AysTzHFgFBC0ePfBYTJ0O7olEatJx5jvSrXYwGE1o7bgLRa84c/B5VeDtCY 8/T5epm+ZpWFjj0zkiYYfW7uTNTmID7dLpXZcdlIiwLte3tB/T0gzMZ9Tb5jhU0FEtl0 5iswMpgYxKWXBhBSLDVwy/DAFcFwA2WHUB0EqCuU15JOd+gkw3HGK+4457wqwZhNXEcq KS5b/ZIE73DLmqOctEVkyjvIRqUEDwWkHJDq7u4RreU98svJoxu6GXfI9Uc9As/HYXzs GfQg== X-Gm-Message-State: ALQs6tB/UypsJk7qfVVVGxq58YBL9oZidJJZ/wnhTpbOjhvxvwx3a14t 6N8hwY62fn2stJWAuNvH6WnSCXmRfK4= X-Google-Smtp-Source: AIpwx4+JWHhG1aABRYiYdhgxlLvGdYKl9nNlfp7W05TgQnMeKYdfLzHgpEaHH+WVu0NkOeqfBX8HcA== X-Received: by 2002:a17:902:b58e:: with SMTP id a14-v6mr17313346pls.175.1523917476463; Mon, 16 Apr 2018 15:24:36 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:f852:23b2:93cc:d900? ([2601:647:4600:3f31:f852:23b2:93cc:d900]) by smtp.gmail.com with ESMTPSA id b65sm36852129pfl.145.2018.04.16.15.24.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 15:24:34 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_481FD60F-799F-4832-9A0D-D423E0FE9E9E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 16 Apr 2018 15:24:33 -0700 In-Reply-To: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> Cc: RTCWeb IETF To: Sean Turner References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 22:24:40 -0000 --Apple-Mail=_481FD60F-799F-4832-9A0D-D423E0FE9E9E Content-Type: multipart/alternative; boundary="Apple-Mail=_F05D8F5C-85EF-4B06-A939-CD5D20FCC2C8" --Apple-Mail=_F05D8F5C-85EF-4B06-A939-CD5D20FCC2C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 7, 2018, at 11:49, Sean Turner wrote: > This is the WGLC for the "WebRTC IP Address Handling Requirements=E2=80=9D= draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. Please = review the draft and send your comments to this list by 2359UTC on 30 = March 30 2017. I apologize for bringing this up so late, but it looks to me like we = should consider phrasing the words for Mode 4 in this draft more = precisely. As shown here = https://bugs.chromium.org/p/chromium/issues/detail?id=3D767304 = and = here https://bugzilla.mozilla.org/show_bug.cgi?id=3D1452713 = implementers = are somewhat confused what to do if Mode 4 is chosen, but no HTTP proxy = is configured. At a minimum I would suggest to insert =E2=80=9CHTTP=E2=80=9D before = each of the occurrences of the word proxy in the description: Mode 4: Force proxy: This forces all WebRTC media traffic through a proxy, if one is configured. If the proxy does not support UDP (as is the case for all HTTP and most SOCKS [RFC1928 = ] proxies), or the WebRTC implementation does not support UDP proxying, the use of UDP will be disabled, and TCP will be used to send and receive media through the proxy. Use of TCP will result in reduced quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. Because apparently some people think of proxies and TURN relays being = the same thing. Which I don=E2=80=99t think is/was the intention here. Second of all I think the draft would benefit from explaining what to do = expect in Mode 4 in the absence of a HTTP proxy. And lastly I think the discussions in the above bug reports have brought = up the point that TURN relays might not be trustworthy either. I=E2=80=99m assuming it=E2=80=99s only a matter of time until when some = evil actors will provide fake TURN implementations to gather the = browsers routable IP from the TURN layer. Therefore I think it would make a lot more sense to specify two = different modes: - Mode 4: Relay only: only TURN relay candidates are gathered. - Mode 5: HTTP proxy only: all WebRTC media traffic is forced through a = HTTP proxy. If no HTTP proxy is configured no candidates are = gathered. I realize that the process might have gotten already to far to follow = this suggestion. Best regards Nils Ohlmeier --Apple-Mail=_F05D8F5C-85EF-4B06-A939-CD5D20FCC2C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Mar 7, 2018, at 11:49, Sean Turner <sean@sn3rd.com> wrote:
This is the WGLC for the "WebRTC IP Address Handling = Requirements=E2=80=9D draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/= .  Please review the draft and send your comments to this list = by 2359UTC on 30 March 30 2017.
I apologize for bringing this up so late, but it = looks to me like we should consider phrasing the words for Mode 4 in = this draft more precisely.

As shown = here https://bugs.chromium.org/p/chromium/issues/detail?id=3D767304<= /a> and here https://bugzilla.mozilla.org/show_bug.cgi?id=3D1452713 = ;implementers are somewhat confused what to do if Mode 4 is chosen, but = no HTTP proxy is configured.

At a = minimum I would suggest to insert =E2=80=9CHTTP=E2=80=9D before each of = the occurrences of the word proxy in the description:

Mode 4:  Force proxy: This =
forces all WebRTC media traffic through a
            proxy, if one is configured.  If the proxy does not support
            UDP (as is the case for all HTTP and most SOCKS [RFC1928]
            proxies), or the WebRTC implementation does not support UDP
            proxying, the use of UDP will be disabled, and TCP will be
            used to send and receive media through the proxy.  Use of
            TCP will result in reduced quality, in addition to any
            performance considerations associated with sending all
            WebRTC media through the proxy server.
Because apparently some people think of proxies and TURN = relays being the same thing. Which I don=E2=80=99t think is/was the = intention here.

Second of all I think the draft would benefit from explaining = what to do expect in Mode 4 in the absence of a HTTP proxy.

And lastly I think the = discussions in the above bug reports have brought up the point that TURN = relays might not be trustworthy either.
I=E2=80=99m = assuming it=E2=80=99s only a matter of time until when some evil actors = will provide fake TURN implementations to gather the browsers routable = IP from the TURN layer.
Therefore I think it = would make a lot more sense to specify two different modes:
- Mode 4: Relay only: only TURN relay candidates are = gathered.
- Mode 5: HTTP proxy only: all WebRTC = media traffic is forced through a HTTP proxy.
  =               If no HTTP proxy is = configured no candidates are gathered.
I realize = that the process might have gotten already to far to follow this = suggestion.

Best= regards
  Nils Ohlmeier
= --Apple-Mail=_F05D8F5C-85EF-4B06-A939-CD5D20FCC2C8-- --Apple-Mail=_481FD60F-799F-4832-9A0D-D423E0FE9E9E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrVIqEACgkQY2o/VmzJ +KHWwhAAvz/pFY+A5aJTsyURxlIXmN4UN60ZywWAIjX6Hnq2oxChi885bybZkger BnqKm/2KtC1d0VPObBMsFnJe8eunAfcQRmChZAI+ywEc0OOnRczfJjJ74IyJwEYd wdMK9NzAlRzmk4BGrJ331ZYr/+3siy7S+gzgZmoE8UmzF+vDP651zQGhyv+0wwSk 8EsQFKTmMczwTki8UQRHsab6Hv/7GVzccVPLCtC8PIgwFvk7SMfuCqsoT0qk2XAM Wv55g2m1KacfUya6SFaJM7yw22RadWc54JivfVKrKg+C2FhJ28nGDb/oVsU1e+wk a6Hlg+JdRm0QvG532yTI8VUM++yLiDQMY9/lb9V4aWW18qhYrf7t3lTz0EMZol9c +yPrPoRfYH51LPtpPX0TihgiZxa33D3iuNfznCa/8/CDKGexk4vZysDDuEuAYGQG LhHUNoxUqHjIpb6Q0jSk/eMkrd7Vj3/z4SY2JyhCyCZ6L1fEIP26o/CdaQP7ZzoV J3ZztX2tMAsXszv9UFsJINJvikewlEwqRzB3BzatRZ8CYeqaGcUBrfWF9QJz5Uff 8/SUOtacrqk7p5QIOgWdlpCBgVb6rJ5usJ7jaGLFW5xJl2NLV6EcVcVqO+TltD0q XCgq/ZNmL8D7Taj3//Z/g3B1N5gFN+KpuYrynNcFGwweo2XuO80= =SJ75 -----END PGP SIGNATURE----- --Apple-Mail=_481FD60F-799F-4832-9A0D-D423E0FE9E9E-- From nobody Mon Apr 16 15:28:31 2018 Return-Path: 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 7917A12EAA5 for ; Mon, 16 Apr 2018 15:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 h353UNYdfCVv for ; Mon, 16 Apr 2018 15:28:24 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73169129C51 for ; Mon, 16 Apr 2018 15:28:24 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id t4so5498208ual.1 for ; Mon, 16 Apr 2018 15:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KnucPYKpklyLn5u6zQUuNBpw4/3TRYw649cNGI4SFCI=; b=su/Q3Z+/h5vy0KTexTcYA3vz9iCVJ6HHD59VlAUzjOdg/t8/l6aWXMF/+hkY/95Mnt 64RgJfSSjV1d++zGwX2dYxWbjtCe1D3Ze5jExmEcq6SlOM3JwLVakzU2tG85XVhEqv70 l5jMEmLHZuB9CASLkHAycebQsW9bl8QdoDyfq6NgS2dBGz2i7MFrM63M+3pn/fQXcB1U mjlw3RBmzEhNj+jPUoNdlX9ZVEe+kdDzGFIKTqtoebT6S1R6KlVeh22hGyaZQyuWDcZP 2FgRGoXZDGrPMFUrmkTS8jdYMs21uJJ3RWdiSBpKFTlfGi5YSI5YvhcmdDiwlDtokz0x ApPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KnucPYKpklyLn5u6zQUuNBpw4/3TRYw649cNGI4SFCI=; b=lc6V53dSSgyMR9UaJrAQjcnvRHbABZoKt8nzQJAav2/E+73JZbWbLLUD9OtTfdKlKL QjwdF18yDS00yYamOcuT5d3j3uA8MzB2DAprhsfJ0jlahpaGrIH2oWI5M0iGgQhEXRRV 5u39VfvPVsVJuwmHrjte6H7xs8UFe0L09KGhxduQz+onNvDX1lebbJ2EFFaUTiZJPDC/ 2QGj1IuTFbKviCBcmqxobhl0Jkutft3yTf4g2pNEzlMIB3ingOhTZgMP30s63JpCFRUr xV6XOCASScAqqTGRG8bFOLL5kMHC8efRxcEFvUzyyqtfNDYc8IYmkUYnk11qh02iorxk IHQA== X-Gm-Message-State: ALQs6tA9ZO4revmeVJ1n0SwCzvHzoLZDkYqWI9h5RYYPtkTHM0lcp5NJ WxGOs8k5c8YISk3YRRee83QLtDJ/SVr20eBseMY2RA== X-Google-Smtp-Source: AIpwx48NxkCA3yivw1VzR4LE6HskoV9MIKJp0p/lyKMTPnHL7Qd3a0fO4gUVRsEh+0qqip2h6q02tWj/KKU6kQJ18Vs= X-Received: by 10.159.35.105 with SMTP id 96mr6540930uae.100.1523917702871; Mon, 16 Apr 2018 15:28:22 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> In-Reply-To: From: Justin Uberti Date: Mon, 16 Apr 2018 22:28:12 +0000 Message-ID: To: Nils Ohlmeier Cc: Sean Turner , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a11352a0659451c0569febdf1" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 22:28:30 -0000 --001a11352a0659451c0569febdf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2018 at 3:24 PM Nils Ohlmeier wrote= : > > On Mar 7, 2018, at 11:49, Sean Turner wrote: > This is the WGLC for the "WebRTC IP Address Handling Requirements=E2=80= =9D draft > available @ > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/. Please > review the draft and send your comments to this list by 2359UTC on 30 Mar= ch > 30 2017. > > > I apologize for bringing this up so late, but it looks to me like we > should consider phrasing the words for Mode 4 in this draft more precisel= y. > > As shown here https://bugs.chromium.org/p/chromium/issues/detail?id=3D767= 304 and > here https://bugzilla.mozilla.org/show_bug.cgi?id=3D1452713 implementers > are somewhat confused what to do if Mode 4 is chosen, but no HTTP proxy i= s > configured. > > At a minimum I would suggest to insert =E2=80=9CHTTP=E2=80=9D before each= of the > occurrences of the word proxy in the description: > > Mode 4: Force proxy: This forces all WebRTC media traffic through a > proxy, if one is configured. If the proxy does not support > UDP (as is the case for all HTTP and most SOCKS [RFC1928 ] > proxies), or the WebRTC implementation does not support UDP > proxying, the use of UDP will be disabled, and TCP will be > used to send and receive media through the proxy. Use of > TCP will result in reduced quality, in addition to any > performance considerations associated with sending all > WebRTC media through the proxy server. > > Because apparently some people think of proxies and TURN relays being the > same thing. Which I don=E2=80=99t think is/was the intention here. > > Second of all I think the draft would benefit from explaining what to do > expect in Mode 4 in the absence of a HTTP proxy. > > And lastly I think the discussions in the above bug reports have brought > up the point that TURN relays might not be trustworthy either. > I=E2=80=99m assuming it=E2=80=99s only a matter of time until when some e= vil actors will > provide fake TURN implementations to gather the browsers routable IP from > the TURN layer. > Therefore I think it would make a lot more sense to specify two different > modes: > - Mode 4: Relay only: only TURN relay candidates are gathered. > - Mode 5: HTTP proxy only: all WebRTC media traffic is forced through a > HTTP proxy. > If no HTTP proxy is configured no candidates are gathered= . > I realize that the process might have gotten already to far to follow thi= s > suggestion. > > How would relay-only help here? The web application can still learn the IP directly from the TURN servers. --001a11352a0659451c0569febdf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Apr 16, 2018 at 3:24 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

On Mar 7, 2018, at 11:49, Sean = Turner <sean@sn3rd.c= om> wrote:
This is the WGLC for the "WebRTC IP A= ddress Handling Requirements=E2=80=9D draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.=C2=A0 = Please review the draft and send your comments to this list by 2359UTC on 3= 0 March 30 2017.

I apologize for= bringing this up so late, but it looks to me like we should consider phras= ing the words for Mode 4 in this draft more precisely.

=
As shown here=C2=A0https://bugs.chromium.org/p/chrom= ium/issues/detail?id=3D767304=C2=A0and here=C2=A0https://bugz= illa.mozilla.org/show_bug.cgi?id=3D1452713=C2=A0implementers are somewh= at confused what to do if Mode 4 is chosen, but no HTTP proxy is configured= .

At a minimum I would suggest to insert =E2=80=9C= HTTP=E2=80=9D before each of the occurrences of the word proxy in the descr= iption:

Mode 4:  Force proxy: This forces all WebRTC media traffic through a
            proxy, if one is configured.  If the proxy does not support
            UDP (as is the case for all HTTP and most SOCKS [RFC1928]
            proxies), or the WebRTC implementation does not support UDP
            proxying, the use of UDP will be disabled, and TCP will be
            used to send and receive media through the proxy.  Use of
            TCP will result in reduced quality, in addition to any
            performance considerations associated with sending all
            WebRTC media through the proxy server.
Because appare= ntly some people think of proxies and TURN relays being the same thing. Whi= ch I don=E2=80=99t think is/was the intention here.

Second of all I think the draft would benefit from explaining what to do = expect in Mode 4 in the absence of a HTTP proxy.

A= nd lastly I think the discussions in the above bug reports have brought up = the point that TURN relays might not be trustworthy either.
I=E2= =80=99m assuming it=E2=80=99s only a matter of time until when some evil ac= tors will provide fake TURN implementations to gather the browsers routable= IP from the TURN layer.
Therefore I think it would make a = lot more sense to specify two different modes:
- Mode 4: Relay on= ly: only TURN relay candidates are gathered.
- Mode 5: HTTP proxy= only: all WebRTC media traffic is forced through a HTTP proxy.
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If no HTTP proxy is= configured no candidates are gathered.
I realize that the proces= s might have gotten already to far to follow this suggestion.

How would relay-only help her= e? The web application can still learn the IP directly from the TURN server= s.
--001a11352a0659451c0569febdf1-- From nobody Mon Apr 16 15:40:03 2018 Return-Path: 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 7B9DE129C6C for ; Mon, 16 Apr 2018 15:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 kk1qVVs2CcN9 for ; Mon, 16 Apr 2018 15:39:59 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AE2129C51 for ; Mon, 16 Apr 2018 15:39:59 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id z135so2077769pgz.3 for ; Mon, 16 Apr 2018 15:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0FLF+Lu5nlh4aV4GzW5ZHpO8w7rRPXTQhwaJ5aljlNo=; b=Q1clFsMsK1KoLVD/ZgS/8rVrmrgxxVLK9Ya6ukOAfBD3pWD40Lq+XI1n6lB71SJ/ga 1MB3Cv9yzz8lOVhgHaK3KBzpoX282Fk2HiYeuM77vuaZknzfEkHRLWJsaViQPObw5Xga DoyLN0TYtnamtDpdyOL3m8qipQO4IxUk28i+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0FLF+Lu5nlh4aV4GzW5ZHpO8w7rRPXTQhwaJ5aljlNo=; b=KdEJWF7okBE6DEwtUABQkS/tyEY08+EvtZZqdp046ZTiWJo3glRp3zDE/dApKQQ3Q6 Ztm/L+xxfVDX9NegHheYAcOYLZUQhq7+4RNTR6YKP3FCDwXOEVDhpUXzl2oHtw9jTkJs GlOVyAGDwEAU9UlOcT7fpX3tgQmQVgJaRy9R7Jrw9XGrm9B5FsiN0MmGBmqtO42qMmPV mbZRmUjJpv2qXRRSE6jYZPVdXuglEhcTud6Qdau1bozR1nBMvBToCg1TB3jkpFxTXdJ0 uyjLh34vgND903YXPpDT9hW0+L04Z2lRhErgJZxsnsZYA8BR5464+DPzslejGGUkmIeY p3bQ== X-Gm-Message-State: ALQs6tBmm7aOGe8t3UJXJSurFh1dFSNv8CRUk7rTEUkiLFqK8yU6c/72 uEPEo2RyBJiDTM3coDlL/K/3Hw== X-Google-Smtp-Source: AIpwx4/34iejPMJnNIJhtiT2+ZnTcOBGhdXI8WiqvnvHfuj1LqIHnoE6gn0UDlGkMYrU8DobM4p2hw== X-Received: by 10.98.36.76 with SMTP id r73mr23276256pfj.108.1523918399241; Mon, 16 Apr 2018 15:39:59 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:f852:23b2:93cc:d900? ([2601:647:4600:3f31:f852:23b2:93cc:d900]) by smtp.gmail.com with ESMTPSA id e19sm14119335pff.169.2018.04.16.15.39.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 15:39:58 -0700 (PDT) From: Nils Ohlmeier Message-Id: <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F3559E09-4FE8-47C2-9396-130384A3EA5B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 16 Apr 2018 15:39:56 -0700 In-Reply-To: Cc: Sean Turner , RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 22:40:01 -0000 --Apple-Mail=_F3559E09-4FE8-47C2-9396-130384A3EA5B Content-Type: multipart/alternative; boundary="Apple-Mail=_AD3741CC-820A-48C9-A487-116E955156D7" --Apple-Mail=_AD3741CC-820A-48C9-A487-116E955156D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 16, 2018, at 15:28, Justin Uberti wrote: > And lastly I think the discussions in the above bug reports have = brought up the point that TURN relays might not be trustworthy either. > I=E2=80=99m assuming it=E2=80=99s only a matter of time until when = some evil actors will provide fake TURN implementations to gather the = browsers routable IP from the TURN layer. > Therefore I think it would make a lot more sense to specify two = different modes: > - Mode 4: Relay only: only TURN relay candidates are gathered. > - Mode 5: HTTP proxy only: all WebRTC media traffic is forced through = a HTTP proxy. > If no HTTP proxy is configured no candidates are = gathered. > I realize that the process might have gotten already to far to follow = this suggestion. >=20 >=20 > How would relay-only help here? The web application can still learn = the IP directly from the TURN servers. At least no IP addresses from your local network are exposed on the = signaling path. Yes if you don=E2=80=99t trust the TURN relay this is the same as Mode = 3. It might make a difference if one has a TURN relay configured in his/her = browser (which results in the web browser ignoring the TURN relays from = web application), which is not part of the web application. Best Nils Ohlmeier. --Apple-Mail=_AD3741CC-820A-48C9-A487-116E955156D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Apr 16, 2018, at 15:28, Justin Uberti <juberti@google.com> = wrote:
And lastly I think the = discussions in the above bug reports have brought up the point that TURN = relays might not be trustworthy either.
I=E2=80=99m = assuming it=E2=80=99s only a matter of time until when some evil actors = will provide fake TURN implementations to gather the browsers routable = IP from the TURN layer.
Therefore I think it = would make a lot more sense to specify two different modes:
- Mode 4: Relay only: only TURN relay candidates are = gathered.
- Mode 5: HTTP proxy only: all WebRTC = media traffic is forced through a HTTP proxy.
  =               If no HTTP proxy is = configured no candidates are gathered.
I realize = that the process might have gotten already to far to follow this = suggestion.


How would relay-only help here? The web = application can still learn the IP directly from the TURN = servers.

At least no IP = addresses from your local network are exposed on the signaling = path.
Yes if you don=E2=80=99t trust the TURN relay = this is the same as Mode 3.
It might make a = difference if one has a TURN relay configured in his/her browser (which = results in the web browser ignoring the TURN relays from web = application), which is not part of the web application.

Best
  Nils Ohlmeier.
= --Apple-Mail=_AD3741CC-820A-48C9-A487-116E955156D7-- --Apple-Mail=_F3559E09-4FE8-47C2-9396-130384A3EA5B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrVJjwACgkQY2o/VmzJ +KFObg//R1SZj25LH0ZeaKa/nOe2R2bULr3RxMWTqSyX+0S87RN4EO1L/+xLr5p/ /MIPy1lZsAD7cezpfl361BUr2lhoyMXlF4bax6WQtVAdfkZYYJld1bW0B1uZshfT n9ock0LvUoMMjaZRr/fAeH8WkjEK02HqMhJu2JnjqQBxO5zVYRMt5C4WxWsnu7lT sTVjqIjFs3DJqNbs1RubZu//FM4QejvCi3gA73fuKBos2uPv0zHTWvnlanBM60KR 7hLR/lZjx/0JdWxCmcYBdORz+zTWNThZ/IpnvCLRgnGI/jN1zXcCoExCZFBSWpi3 w3z8DHWjmD2qNxDuCkqm/B0RjFNs/mVdJcd/4awWm7nuLMbnBLepzu6I7kcIscQl Sm+VlZX/JgJr2HSniJ1ZhzIruLq8GSg/mIptTviTYQrzsuWAzBgnLhKbo9EH4AIh YtabaOYQwHl+orAd6ryfpNnGIe3MBVgPCuvxbNy5ZSEup50D3qmSbzS5ndwSTrxb ITNTH+20OSe55QJOKofeaeb1wzKHTRotDVrCNbNdDh62K7zs+WwSeLHnwQbzjP9t JUNyqAwbp1SB8KNN7skTAzG0SNTrDKb5KpdVRrqNhpK88xQZIWHsKzu8voIkrMi4 R5LYhZse5lxQSdM0VvFgnrq7bEwE0tkAWKE3HO0Qcs4mh7QC8Xg= =p74h -----END PGP SIGNATURE----- --Apple-Mail=_F3559E09-4FE8-47C2-9396-130384A3EA5B-- From nobody Mon Apr 16 15:44:36 2018 Return-Path: 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 ABF6112AF83 for ; Mon, 16 Apr 2018 15:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 RkmNb9E83x52 for ; Mon, 16 Apr 2018 15:44:34 -0700 (PDT) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD719129C51 for ; Mon, 16 Apr 2018 15:44:33 -0700 (PDT) Received: by mail-pl0-x232.google.com with SMTP id t22-v6so2226311plo.7 for ; Mon, 16 Apr 2018 15:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mA0SQrt7wqK1xtcbtZRTuRz6LWQa79VhP7yv/QS8XY4=; b=fgJtDC4KQI5AVP5VJEnlCIOvMKWfL/MJxzKtjO1g9m2EkRysvR3JsBoO8irscUnTK6 zDo60zT9HPZ+dv35lBf8dbR5i07kwO9bMddRIR4BhkSxTonGCIA2D4RmD0KutqveEWWQ m3BvDK/8TsJoN0NIo38gCxHXvDXpaF2TEhjp8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mA0SQrt7wqK1xtcbtZRTuRz6LWQa79VhP7yv/QS8XY4=; b=XNljhlWdcgsbyaEq5epnxni7iHvMouWPA4WRyBNNRn3+77YhnJyBFvKI2Un+2oZVHi hiBPB2LkNTmO2dJmg+wcDpAPGoLsM+XHQNI99/xUrjVTA8NhiMwUIlCuXRnL3o+JWCju /coVUFvCg0ubjiqzXXVyGCD2BbR9/GnP9sRu3kooBrUzuf2/SBr52xNq4fsNuIJ9ur/8 T4ax0eEBBtldmvUcas1ITMUqxFai85K7I37Ek4yu2F8DgqTky1AXkM3xJKJuAE1Lel8K jveLGUtYwI+HbOHiZVo3v6LS8obVb/2BiV/AXFk3iRTpw3MYBo22/2BdJlvj4386H2Ca rcew== X-Gm-Message-State: ALQs6tCv2eoljR3Bkqvgn8oK2JvVVlcayMdXQ1vJE6OyrsILDUcRJRMW BdgMOwxzc0v4jIAVrtqRs+2cQw== X-Google-Smtp-Source: AIpwx49AwuppCs51jEFmIRAPn+7SrVV9HzT3og2SIqKKiPrjgl6+BgnrDzguv2i8KMGqjUq7WfgcVA== X-Received: by 2002:a17:902:9898:: with SMTP id s24-v6mr17039307plp.51.1523918673407; Mon, 16 Apr 2018 15:44:33 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:f852:23b2:93cc:d900? ([2601:647:4600:3f31:f852:23b2:93cc:d900]) by smtp.gmail.com with ESMTPSA id t25sm21477474pfh.184.2018.04.16.15.44.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 15:44:32 -0700 (PDT) From: Nils Ohlmeier Message-Id: <4ACBAB83-D717-402D-AEE6-0104BFEDC686@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2042A2D5-7D5B-4184-920A-6314DBD92DD2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 16 Apr 2018 15:44:30 -0700 In-Reply-To: <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> Cc: Sean Turner , RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 22:44:35 -0000 --Apple-Mail=_2042A2D5-7D5B-4184-920A-6314DBD92DD2 Content-Type: multipart/alternative; boundary="Apple-Mail=_E2B71D75-B0FD-4AAA-949B-A46E7377E0FF" --Apple-Mail=_E2B71D75-B0FD-4AAA-949B-A46E7377E0FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 16, 2018, at 15:39, Nils Ohlmeier = wrote: >=20 >=20 >> On Apr 16, 2018, at 15:28, Justin Uberti > wrote: >> And lastly I think the discussions in the above bug reports have = brought up the point that TURN relays might not be trustworthy either. >> I=E2=80=99m assuming it=E2=80=99s only a matter of time until when = some evil actors will provide fake TURN implementations to gather the = browsers routable IP from the TURN layer. >> Therefore I think it would make a lot more sense to specify two = different modes: >> - Mode 4: Relay only: only TURN relay candidates are gathered. >> - Mode 5: HTTP proxy only: all WebRTC media traffic is forced through = a HTTP proxy. >> If no HTTP proxy is configured no candidates are = gathered. >> I realize that the process might have gotten already to far to follow = this suggestion. >>=20 >>=20 >> How would relay-only help here? The web application can still learn = the IP directly from the TURN servers. >=20 > At least no IP addresses from your local network are exposed on the = signaling path. > Yes if you don=E2=80=99t trust the TURN relay this is the same as Mode = 3. > It might make a difference if one has a TURN relay configured in = his/her browser (which results in the web browser ignoring the TURN = relays from web application), which is not part of the web application. A relay-only mode would also help if you don=E2=80=99t want to hand out = your IP addresses to the others side of the PeerConnection, but you do = trust the TURN server and web application. Best Nils Ohlmeier --Apple-Mail=_E2B71D75-B0FD-4AAA-949B-A46E7377E0FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 16, 2018, at 15:39, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:


On Apr = 16, 2018, at 15:28, Justin Uberti <juberti@google.com> = wrote:
And lastly I think the = discussions in the above bug reports have brought up the point that TURN = relays might not be trustworthy either.
I=E2=80=99m = assuming it=E2=80=99s only a matter of time until when some evil actors = will provide fake TURN implementations to gather the browsers routable = IP from the TURN layer.
Therefore I think it = would make a lot more sense to specify two different modes:
- Mode 4: Relay only: only TURN relay candidates are = gathered.
- Mode 5: HTTP proxy only: all WebRTC = media traffic is forced through a HTTP proxy.
  =               If no HTTP proxy is = configured no candidates are gathered.
I realize = that the process might have gotten already to far to follow this = suggestion.


How would relay-only help here? The web = application can still learn the IP directly from the TURN = servers.

At least no IP = addresses from your local network are exposed on the signaling = path.
Yes if you don=E2=80=99t trust the TURN relay = this is the same as Mode 3.
It might make a = difference if one has a TURN relay configured in his/her browser (which = results in the web browser ignoring the TURN relays from web = application), which is not part of the web = application.

A = relay-only mode would also help if you don=E2=80=99t want to hand out = your IP addresses to the others side of the PeerConnection, but you do = trust the TURN server and web application.

Best
  Nils Ohlmeier


= --Apple-Mail=_E2B71D75-B0FD-4AAA-949B-A46E7377E0FF-- --Apple-Mail=_2042A2D5-7D5B-4184-920A-6314DBD92DD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrVJ04ACgkQY2o/VmzJ +KF3AQ//S+rpEEF+juSEevOQFqDskA2kne7SlmHPVLOarPbfewShVSSmodQ1dOYw f7mBFSOTeVCk2nCKnmEfY5az8EDsL+Z4lE7hIB4FDEXYEj0BLhWoU90+hTdjOLeh GHTQWduwMloYEEXTIeGgeds25CKIGer7W8v1xi1wWEvIThuYl2HuogO7bUMcalCw WWOXCknuLGTW2KlHIrzR4dWdIvk1Rh+TzrsLSIEl177gNzunEJlNT5dy06BwyE3Y 3ObYcmXR6oEw5wqJTgXWUZHZZ6Ow8nbKzeZ12SgoGgIlkr0Cv3LL/cl4Gy935tsF e1ifVq05pGlxRDz0ORiRlGIS9YMfR+3OBB+QB2xZCyprYP8VCqlpOPyrmUiVYMC1 SYBVr0fKBygb5Q1FaWc0uB4KC2CgJLzIYcM1dKCotB6+GthCIGsDC9Ify9Lhz+yN hZ0o4LAeNBcP6bLRGRICIDewYl7srfCBO5mPLj6+ojv0gXt9vnpyzetx4yaw/zsb hVgXsRiusL4qZ+c+0BgnAeI7l6U9LAOJElT4HaRjHUjg8xuMqx4PtnNgAn5lW/yP mSKgPoHtuY9lfIj2JVDt8r+RItGgQzvK0dkBDg3a9FQ9wMeRfFd6zjX4yZp8EjGP X4bfHA8/G7pOMouVVh8JtOfwsd8NRgY3fkyiznpoVQym5f5UNcw= =uX7t -----END PGP SIGNATURE----- --Apple-Mail=_2042A2D5-7D5B-4184-920A-6314DBD92DD2-- From nobody Tue Apr 17 02:15:31 2018 Return-Path: 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 A03CF12D779 for ; Tue, 17 Apr 2018 02:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 28SeoYALXWcv for ; Tue, 17 Apr 2018 02:15:26 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E00212741D for ; Tue, 17 Apr 2018 02:15:26 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id q38so11978558uad.5 for ; Tue, 17 Apr 2018 02:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rvnI1ani+WqKxx3wSSUG5NaJgKeEYo76lvxz9aXiaOs=; b=l1uwv78Aqy+z1gqyqDbyoubI6H6veL4ylPTuylxewbCiwh4SSC7MdQzjajhcASnVGH KCNlruWrGJc292S1LIt+klraREWqBmzDwMZ89w8OmTj2EdMheHCnRMClYtCUM4xECROS pBIjNH1Trni//gvKz79fW/YJk5dKHGGMFiBawQTxo7XU8T4yo0HHsBcVRaF8RwfOgNsH WuE7UHg20jIfA2agWxVTp91gOTuzeJgfYWJ39gDVnxX9p5ytBk0PmL1nPbzY++TTCO5K Z8F5mzJP9S9Vkw+Hbj0Qfzk+d8Q2tQo0eClqt6pKu7K+oGU7aK2h+/TNcnGui/xCni1X yDtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rvnI1ani+WqKxx3wSSUG5NaJgKeEYo76lvxz9aXiaOs=; b=cPXFjNAFWt8M6cLokS79YWKWylBbeljOeXrWS0bXrqJJXg9m3llgfBJ4Iuan/1+tze 6Os2tmf3nrAgmuLwHN6DcHfyscnR2tc4J6dLiiHU2gk5+CCYZ7crHsG1PWoS/qUyeN1j jx4VqYF4iaDelDc8rKmQ+JuVMxtrbxCGbE6tjUr73/wcLLxpDqMSDpLMGPobfj32zXay v4MNQukRyUf1AkmioAf7usG/M7rSSafXGc0gxguvP5BrHUTL8rEKsol54Sv73AZ1YudY lIiLnRe9Lpj1lMDhNoKXWzNfwJEg23d3WH33yoKTYtvgwcqUdnHk8gUrnxZcQvGqAfnk dHHg== X-Gm-Message-State: ALQs6tCEtMNWZ7SE9Xubu3EYa+sb6lTEC/yUHfVd+RWIT+NTS2B1wNtR 8JxATJ2nViln9MlHxFrrmzO7FRdFoHPEtTAWz3Bo4SyL X-Google-Smtp-Source: AIpwx4/XlF3Xl2tDNk+MM6pWem50gKSs5ZEQTkCDKBEf0HmrsC+8TSZunLf+S5vlH3TwYTwn0xx3w9df6GelVLAf6a4= X-Received: by 10.176.95.93 with SMTP id z29mr791234uah.87.1523956524833; Tue, 17 Apr 2018 02:15:24 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> In-Reply-To: <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> From: Justin Uberti Date: Tue, 17 Apr 2018 09:15:14 +0000 Message-ID: To: Nils Ohlmeier Cc: Sean Turner , RTCWeb IETF Content-Type: multipart/alternative; boundary="f403045fe14c517239056a07c7cb" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 09:15:30 -0000 --f403045fe14c517239056a07c7cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2018 at 3:40 PM Nils Ohlmeier wrote= : > > On Apr 16, 2018, at 15:28, Justin Uberti wrote: > >> And lastly I think the discussions in the above bug reports have brought >> up the point that TURN relays might not be trustworthy either. >> I=E2=80=99m assuming it=E2=80=99s only a matter of time until when some = evil actors will >> provide fake TURN implementations to gather the browsers routable IP fro= m >> the TURN layer. >> Therefore I think it would make a lot more sense to specify two differen= t >> modes: >> - Mode 4: Relay only: only TURN relay candidates are gathered. >> - Mode 5: HTTP proxy only: all WebRTC media traffic is forced through a >> HTTP proxy. >> If no HTTP proxy is configured no candidates are gathere= d. >> I realize that the process might have gotten already to far to follow >> this suggestion. >> >> > How would relay-only help here? The web application can still learn the I= P > directly from the TURN servers. > > > At least no IP addresses from your local network are exposed on the > signaling path. > Yes if you don=E2=80=99t trust the TURN relay this is the same as Mode 3. > It might make a difference if one has a TURN relay configured in his/her > browser (which results in the web browser ignoring the TURN relays from w= eb > application), which is not part of the web application. > IMO "trusting the TURN relay but not the application" is not a significant enough benefit to merit adding specific functionality for. Forced TURN relays would be covered as part of Mode 4. --f403045fe14c517239056a07c7cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Apr 16, 2018 at 3:40 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

On Apr 16, 2018, at 15:28, Just= in Uberti <juber= ti@google.com> wrote:
And lastly I think the discussions i= n the above bug reports have brought up the point that TURN relays might no= t be trustworthy either.
I=E2=80=99m assuming it=E2=80=99s only a= matter of time until when some evil actors will provide fake TURN implemen= tations to gather the browsers routable IP from the TURN layer.
=
Therefore I think it would make a lot more sense to specify two differ= ent modes:
- Mode 4: Relay only: only TURN relay candidates are g= athered.
- Mode 5: HTTP proxy only: all WebRTC media traffic is f= orced through a HTTP proxy.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 If no HTTP proxy is configured no candidates are gathe= red.
I realize that the process might have gotten already to far = to follow this suggestion.


=
How would relay-only help here? The web application can still le= arn the IP directly from the TURN servers.

At least no IP addresses from your local = network are exposed on the signaling path.
Yes if you don=E2=80= =99t trust the TURN relay this is the same as Mode 3.
It might ma= ke a difference if one has a TURN relay configured in his/her browser (whic= h results in the web browser ignoring the TURN relays from web application)= , which is not part of the web application.
IMO "trusting the TURN relay but not the application"= ; is not a significant enough benefit to merit adding specific functionalit= y for.

Forced TURN relays would be covered as part= of Mode 4.
--f403045fe14c517239056a07c7cb-- From nobody Tue Apr 17 05:16:09 2018 Return-Path: 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 631C512EB14 for ; Tue, 17 Apr 2018 05:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zP8dQ3-hqGAC for ; Tue, 17 Apr 2018 05:16:04 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0591D12EB0B for ; Tue, 17 Apr 2018 05:16:04 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id u11so34874705wri.12 for ; Tue, 17 Apr 2018 05:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=P1ko461rVuZGKcWzu6naTOWKD+8vfMaR8CfXDZMsSFw=; b=qC/+tK4kqL2JOiKNWPrfx670ZgqUloa/YHqA+2njEQX8eoDPYBcdle12D1IMSW1P8g xyOT8Hw5RcoOcllIK7UfveSWRxdyyDYo1TLtSEArbO51deEbZDyU6kv5VYHBDLXVHrWy 8fnCgPAxP3+vp/2UQjhfwEue4mbynuqCo4NwBBVXY4utvw1GmrmSxFsLFwRUQPD1agT3 NOr1j+fo9WvGZA8WmVvTNitsPptkdrdmErC8lSukss0zNG/Un/VI0jZ/W1KAyNHTNXM7 SijtywUdG7Avvn1QH+S+rlV10hPsKaC0uHF8eMRj9LcVyvMAlAStvYgFFhdhjiYxLYg0 +GhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=P1ko461rVuZGKcWzu6naTOWKD+8vfMaR8CfXDZMsSFw=; b=rnBgm9jJexot3oZ52Cl4H58Mfo5GNNM36YQYaZYQrYo5SUoV9PUhvzJXjgq9ggOYrH tUUcp48A2cj4QdTD0VGa3TVS4CcnqsbsCGidG4Hbgmfkzr+8EFxpUji052rFZARsIQyE Ira/wWnR4r1l8W2j1CJ7awQz06dokEDn16ItVd8s/KVM5F0MnRXZNafXsj2ARuebCGgb VtWFBLMoCIAFwfFuBLQtPvl9D/1m/NJlnbsQ44fPgsMppTRe6ziGOqC7rCbEqIQK8upQ 9psr+Y2lrWFR+lQ/iAnGMDU2j28Jqcg7h9fsKUzwnLuAY8CkX+lzrvXfyXbQPE1tgdCu sRYA== X-Gm-Message-State: ALQs6tBxkmTWvckXdht20TDqedqoIaWf2cTbX4bi5Kqr7naxNljpf6rC HMumWrj1RsjXCFNQCziW7uYtFA== X-Google-Smtp-Source: AIpwx4+QjYuaYpEae78jqJyR67O1BpGWr0zMBRbO2GEFqBBJaQYkRrvIJdZpG7vwpffoeE0AkRF+rw== X-Received: by 10.80.241.154 with SMTP id x26mr2825385edl.59.1523967362258; Tue, 17 Apr 2018 05:16:02 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:5dbf:b9ae:ee71:ab49? (p200300CD6F24EB005DBFB9AEEE71AB49.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:5dbf:b9ae:ee71:ab49]) by smtp.gmail.com with ESMTPSA id s9sm8640418edc.85.2018.04.17.05.16.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 05:16:01 -0700 (PDT) To: rtcweb@ietf.org References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: Date: Tue, 17 Apr 2018 14:16:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 12:16:07 -0000 On 16.04.2018 23:06, Justin Uberti wrote: > Here's a specific and minimal proposal, which is a slight modification > of Sean's > proposal in https://github.com/juberti/draughts/pull/98/files: > > *The details of this consent are left to the implementation; one potential > mechanism is to tie this consent to getUserMedia consent. Alternatively > implementations can provide a specific mechanism to obtain user consent > where needed, e.g., when a VPN is in use.* > > Are folks in favor of: > a) the text above > b) Sean's proposal (without the boldface) > c) something else Voting for b). Cheers Lennart From nobody Tue Apr 17 05:40:43 2018 Return-Path: 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 DD65312EB2A for ; Tue, 17 Apr 2018 05:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 fdFXfTeSSa4A for ; Tue, 17 Apr 2018 05:40:38 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) (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 139C412EB26 for ; Tue, 17 Apr 2018 05:40:37 -0700 (PDT) Received: (qmail 73347 invoked from network); 17 Apr 2018 12:40:36 -0000 X-APM-Authkey: 255286/0(159927/0) 1214 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 17 Apr 2018 12:40:36 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 607A218A11D3; Tue, 17 Apr 2018 13:40:36 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pjqTpedyEZR9; Tue, 17 Apr 2018 13:40:36 +0100 (BST) Received: from phage-rock.fritz.box (p5B28C899.dip0.t-ipconnect.de [91.40.200.153]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 1566718A0124; Tue, 17 Apr 2018 13:40:36 +0100 (BST) From: westhawk Message-Id: <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_8359CD96-C25E-4931-ACD5-D08EC148DEB5" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 17 Apr 2018 14:40:34 +0200 In-Reply-To: Cc: RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 12:40:41 -0000 --Apple-Mail=_8359CD96-C25E-4931-ACD5-D08EC148DEB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 16 Apr 2018, at 23:06, Justin Uberti = wrote: >=20 > Here's a specific and minimal proposal, which is a slight modification = of Sean's proposal in https://github.com/juberti/draughts/pull/98/files = : >=20 > The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use. >=20 > b) Sean's proposal (without the boldface) b) --Apple-Mail=_8359CD96-C25E-4931-ACD5-D08EC148DEB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 16 Apr 2018, at 23:06, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

Here's a specific and minimal proposal, which = is a slight modification of Sean's proposal in https://github.com/juberti/draughts/pull/98/files:

The details of this consent are left to the = implementation; one potential mechanism is to tie this consent to = getUserMedia consent. Alternatively implementations can provide a = specific mechanism to obtain user consent where needed, = e.g., when a VPN is in use.

b) Sean's proposal = (without the boldface)

b)

= --Apple-Mail=_8359CD96-C25E-4931-ACD5-D08EC148DEB5-- From nobody Tue Apr 17 05:40:52 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8996D12EB26 for ; Tue, 17 Apr 2018 05:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523968842; bh=hcGLjSsvNWmwUb/wn5qS1aV+b5Sr4NPUkfMeXB+So1I=; h=From:Subject:Date:In-Reply-To:Cc:References:To; b=JN/pDIVTTNEyAlACjbRbbLSxvXZXJ3DesxniL7j+cCvevJYKV3QWlsrMupgwVcdZh HXMh3G0vEmUsakf9CqSVxd2T8qzpWI9OTNlx72uSWB4pAc6iJCnFl+2Q8A7Pj9U06M pcYyu+6s2z9EWwtKSFk+utSyWwEBOXpxp9swaXRU= X-Mailbox-Line: From thp@westhawk.co.uk Tue Apr 17 05:40:42 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C6112EB2A for ; Tue, 17 Apr 2018 05:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1523968842; bh=hcGLjSsvNWmwUb/wn5qS1aV+b5Sr4NPUkfMeXB+So1I=; h=From:Subject:Date:In-Reply-To:Cc:References:To; b=JN/pDIVTTNEyAlACjbRbbLSxvXZXJ3DesxniL7j+cCvevJYKV3QWlsrMupgwVcdZh HXMh3G0vEmUsakf9CqSVxd2T8qzpWI9OTNlx72uSWB4pAc6iJCnFl+2Q8A7Pj9U06M pcYyu+6s2z9EWwtKSFk+utSyWwEBOXpxp9swaXRU= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1597B12EB26 for ; Tue, 17 Apr 2018 05:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 oyNOMOawHG36 for ; Tue, 17 Apr 2018 05:40:38 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) (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 152D712EB27 for ; Tue, 17 Apr 2018 05:40:37 -0700 (PDT) Received: (qmail 73347 invoked from network); 17 Apr 2018 12:40:36 -0000 X-APM-Authkey: 255286/0(159927/0) 1214 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 17 Apr 2018 12:40:36 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 607A218A11D3; Tue, 17 Apr 2018 13:40:36 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pjqTpedyEZR9; Tue, 17 Apr 2018 13:40:36 +0100 (BST) Received: from phage-rock.fritz.box (p5B28C899.dip0.t-ipconnect.de [91.40.200.153]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 1566718A0124; Tue, 17 Apr 2018 13:40:36 +0100 (BST) From: westhawk Message-Id: <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_8359CD96-C25E-4931-ACD5-D08EC148DEB5" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 17 Apr 2018 14:40:34 +0200 In-Reply-To: Cc: RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.6.18) To: Justin Uberti Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 12:40:43 -0000 --Apple-Mail=_8359CD96-C25E-4931-ACD5-D08EC148DEB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 16 Apr 2018, at 23:06, Justin Uberti = wrote: >=20 > Here's a specific and minimal proposal, which is a slight modification = of Sean's proposal in https://github.com/juberti/draughts/pull/98/files = : >=20 > The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use. >=20 > b) Sean's proposal (without the boldface) b) --Apple-Mail=_8359CD96-C25E-4931-ACD5-D08EC148DEB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 16 Apr 2018, at 23:06, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

Here's a specific and minimal proposal, which = is a slight modification of Sean's proposal in https://github.com/juberti/draughts/pull/98/files:

The details of this consent are left to the = implementation; one potential mechanism is to tie this consent to = getUserMedia consent. Alternatively implementations can provide a = specific mechanism to obtain user consent where needed, = e.g., when a VPN is in use.

b) Sean's proposal = (without the boldface)

b)

= --Apple-Mail=_8359CD96-C25E-4931-ACD5-D08EC148DEB5-- From nobody Tue Apr 17 08:00:40 2018 Return-Path: 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 F342A126C0F for ; Sun, 15 Apr 2018 00:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 wCtlHQdf4lV6 for ; Sun, 15 Apr 2018 00:16:54 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 8E6EC1275AB for ; Sun, 15 Apr 2018 00:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1523776610; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ScDIy4cAoVJ6ynkQZLSQ4QpubT8ryhvVFR8IFfTtWJI=; b=DJiMUCc8+gav6KOPmoH1fQQzVWnJt/fnveWkYqHV1jiV6XzXKaUzxJc9K8ns4xTB 85VJtJdoX7iobRziDwWGSe6gTCZTGG5sdYK3LWI234GzCDCQsUYlJWPT8jEPUKAl 9wMuuOjLyXFzMQTttDeCMW4gY9obp+PZQG+ryObWlxI=; X-AuditID: c1b4fb2d-82dff70000003563-2a-5ad2fc616201 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 24.D7.13667.16CF2DA5; Sun, 15 Apr 2018 09:16:50 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0382.000; Sun, 15 Apr 2018 09:16:49 +0200 From: Christer Holmberg To: Ben Campbell CC: Peter Saint-Andre , Suhas Nandakumar , Adam Roach , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , Flemming Andreasen , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN///2vYCAAnGPMA== Date: Sun, 15 Apr 2018 07:16:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> In-Reply-To: <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7k27Sn0tRBnfeMVvs+buI3WJ+52l2 ix9rlzNbvL+ga/HtQq3FjD8TmS3O71zPZDF1+WMWi7X/2tktnq08xWixc24HswO3x5TfG1k9 ds66y+6xZMlPJo++A12sHrN2PmEJYI3isklJzcksSy3St0vgyph19wB7QY9KxZQ5BxkbGKco dzFyckgImEgcbbjN1sXIxSEkcIRRoqfxOyuEs5hRYsu8u0xdjBwcbAIWEt3/tEEaRASUJJ43 b2UBqWEW2MAssbL1GitIQligQGLjnFY2iKJCibU7HoFNFRFYxiixcMUidpAEi4CqxKNT98Aa eAV8JS6eOcMCsW0Kp8SP05+ZQRKcAvYS6/evBStiFBCT+H5qDROIzSwgLnHryXwmiLsFJJbs Oc8MYYtKvHz8jxXCVpJ4+n8J2NXMApoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGEVnIZk6C6Fj FpKOWUg6FjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjM6DW37r7mBc/drxEKMAB6MS D2/X+0tRQqyJZcWVuYcYJTiYlUR4S9yBQrwpiZVVqUX58UWlOanFhxilOViUxHn1Vu2JEhJI TyxJzU5NLUgtgskycXBKNTDmlRzYUqQqJjfrmsB/25iEbzZP4vt+vr47r2zxPJc5fuke70Xm vBa86/t9zjYh9+i6b7Mm3FEv+/Nv/8KrTszmS0tajNlrmv9ktZzdvOeZPfOjOD7FSMWVpypV 9TbtfbqrQuKU4OuG870hu3IjGM2E/uY/2xqTf3X615Kz+zfLf3uzdI/C2YIlSizFGYmGWsxF xYkAhmDsscoCAAA= Archived-At: X-Mailman-Approved-At: Tue, 17 Apr 2018 08:00:39 -0700 Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2018 07:16:55 -0000 SGksDQoNCj4gWWVzLiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB0byBqdXN0IG1vdmUgdGhlIHJl ZmVyZW5jZXMgaW4gSlNFUCB0byBwb2ludCB0byBtbXVzaWMtdHJpY2tsZS1zaXAsIG9yIGRvIHNv bWV0aGluZyBkaWZmZXJlbnQuDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGEg bGlzdCBvZiBhbGwgdGhlIHJlZmVyZW5jZSBpbnN0YW5jZXMgdGhhdCBuZWVkIHRvIGJlIG1vZGlm aWVkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo+IE9uIEFwciAxMywgMjAxOCwgYXQgMToy OSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4g d3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IEluIGFkZGl0aW9uLCBhcyBJIG1lbnRpb25lZCBlYXJs aWVyLCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgSlNFUCByZWZlcmVuY2VzIGRyYWZ0LWljZS10cmlj a2xlIGZvciB0aGluZ3MgYW5kIHByb2NlZHVyZXMgdGhhdCBkb27igJl0IGV4aXN0IGluIGRyYWZ0 LWljZS10cmlja2xlLiBJbnN0ZWFkIHRob3NlIHJlZmVyZW5jZXMgc2hvdWxkIGJlIHRvIGRyYWZ0 LW1tdXNpYy10cmlja2xlLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IENocmlzdGVyDQo+IA0KPiBT ZW50IGZyb20gbXkgaVBob25lDQo+IA0KPiBPbiAxMyBBcHIgMjAxOCwgYXQgMTcuNTYsIEJlbiBD YW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPiB3cm90ZToNCj4gDQo+PiANCj4+IA0KPj4+IE9uIEFw ciAxMywgMjAxOCwgYXQgNzowNiBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGksDQo+Pj4gDQo+Pj4+PiBPbiBB cHIgNCwgMjAxOCwgYXQgMTE6MDcgQU0sIFBldGVyIFNhaW50LUFuZHJlIA0KPj4+Pj4gPHN0cGV0 ZXJAbW96aWxsYS5jb20+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gT24gNC8zLzE4IDI6 NDEgUE0sIFN1aGFzIE5hbmRha3VtYXIgd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g T24gVHVlLCBBcHIgMywgMjAxOCBhdCAxMjoyMiBQTSwgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1 bS5jb20gDQo+Pj4+Pj4gPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+PiB3cm90ZToNCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+Pj4gT24gQXByIDMsIDIwMTgsIGF0IDI6MjAgUE0sIFBl dGVyIFNhaW50LUFuZHJlIA0KPj4+Pj4+PiA8c3RwZXRlckBtb3ppbGxhLmNvbSA8bWFpbHRvOnN0 cGV0ZXJAbW96aWxsYS5jb20+PiB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IE9uIDQvMy8xOCAx MjoyNyBQTSwgU3VoYXMgTmFuZGFrdW1hciB3cm90ZToNCj4+Pj4+Pj4+IEp1c3QgdG8gY29tcGxl dGUsIGljZS1iaXMgZG9lc27EhXQgbm9ybWF0aXZlbHkgcmVmZXJlbmNlIA0KPj4+Pj4+Pj4gaWNl LXNpcC1TRFAgZHJhZnQgd2hlbiBpdCBtb3ZlZCB0byB1c2luZyDFgnVzYWdlcyDFgiBpbmRpcmVj dGlvbnMgDQo+Pj4+Pj4+PiBmb3Igc2lnbmFsaW5nIHByb3RvY29scy4NCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gDQo+Pj4+Pj4+PiBUcmlja2xlIGljZSBjYW4gdXNlIHNpbWlsYXIgYXBwcm9hY2ggYW5k IHJlZmVyIHRvIHRyaWNrbGUtc2lwIA0KPj4+Pj4+Pj4gYXMgdXNhZ2UgZm9yIHRyaWNrbGUuDQo+ Pj4+Pj4+IA0KPj4+Pj4+PiBJdCBhbHJlYWR5IGRvZXMuIFRoYXQncyB3aHkgd2UgcHVsbGVkIGFs bCB0aGUgU0RQL1NJUCBzdHVmZiBvdXQgDQo+Pj4+Pj4+IG9mIGRyYWZ0LWlldGYtaWNlLXRyaWNr bGUuDQo+Pj4+Pj4gDQo+Pj4+Pj4gIEkgYXNzdW1lIFN1aGFzIG1lYW50IHNlcGFyYXRpbmcgdGhl IFNEUCBzdHVmZiBmcm9tIHRoZSBTSVAgDQo+Pj4+Pj4gc3R1ZmYuIChJICBhbHNvIGFzc3VtZSBo ZSB3aWxsIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy4pDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+ Pj4gVGhhdCdzIHJpZ2h0IEJlbiAuLiBJIHdhcyBqdXN0IHRoaW5raW5nIG1pbmltYWwgbG9jYWxp emVkIGNoYW5nZXMgDQo+Pj4+Pj4gKHRodXMgc21hbGwgdGltZSB0byBnZXQgbmV3IGRyYWZ0IGRv bmUpIGFuZCB0aGVuIGFza2luZyB0cmlja2xlLCANCj4+Pj4+PiB0cmlja2xlLXNpcCB0byByZWZl ciB0byB0aGUgbmV3IG9uZS4gKHdvcmsgZG9uZSB0byByZWZlciBpcyBtdWNoIA0KPj4+Pj4+IHNt YWxsZXIgZm9yIHRoZXNlIGRyYWZ0cyB0aGF0IGFyZSBhdCB0aGUgdmVyeSBlbmQgb2YgYXBwcm92 YWwgDQo+Pj4+Pj4gam91cm5leSkNCj4+Pj4+PiANCj4+Pj4+PiBJIGRvIGFncmVlIHdpdGggQWRh bSwgbm8gbWF0dGVyIHdoYXQgdmVyc2lvbiBvZiB0aGUgcHJvcG9zYWwgd2UgDQo+Pj4+Pj4gcGlj aywgdGhlcmUgaXMgc29tZSB3b3JrIHRoYXQgbmVlZHMgdG8gYmUgZG9uZSBhbmQgd2Ugc2hvdWxk IGRvIA0KPj4+Pj4+IGl0Lg0KPj4+Pj4gDQo+Pj4+PiBUaGVzZSBkb2N1bWVudHMgYXJlIG9uIHRo ZSB0ZWxlY2hhdCB0b21vcnJvdy4gQXJlIHdlIHByb3Bvc2luZyB0byANCj4+Pj4+IGRlbGF5IGNv bnNpZGVyYXRpb24gYnkgdGhlIElFU0cgd2hpbGUgd2UgZ2V0IHRoaXMgbWVzcyBzb3J0ZWQgb3V0 PyANCj4+Pj4+IDstKQ0KPj4+PiANCj4+Pj4gSGkgUGV0ZXIsDQo+Pj4+IA0KPj4+PiBJIGN1cnJl bnRseSBwbGFuIHRvIGxlYXZlIGl0IG9uLiBXZSBtYXkgZGlzY3VzcyBhIHdheSBmb3J3YXJkIG9u IA0KPj4+PiB0aGUgdGVsZWNoYXQuIEFsc28sIEnEhWQgbGlrZSB0byBnZXQgZmVlZGJhY2sgb24g dGhlIHJlc3Qgb2YgdGhlIA0KPj4+PiBkcmFmdChzKSBmcm9tIHRoZSBvdGhlciBBRHMgc29vbmVy IHRoYW4gbGF0ZXIuDQo+Pj4gDQo+Pj4gRGlkIHlvdSBkaXNjdXNzIHRoaXMgYXQgdGhlIHRlbGVj aGF0Pw0KPj4+IA0KPj4+IEFueSBvdGhlciBkaXNjdXNzaW9ucyBvbiBob3cgdG8gbW92ZSBmb3J3 YXJkIHdpdGggdGhpcz8NCj4+IA0KPj4gWWVzLCBBZGFtIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNz aW5nIHRoaXMgd2l0aCB0aGUgUlRDV0VCIGNoYWlycy4gV2XigJl2ZSBzaW5jZSBkaXNjb3ZlcmVk IHRoYXQgdGhpcyBpcyBub3QgdGhlIG9ubHkgSlNFUCBub3JtYXRpdmUgcmVmZXJlbmNlIGNoYWlu IGJhY2sgdG8gU0lQLiBUaGUgUlRDV0VCIGNoYWlycyBhcmUgY3VycmVudGx5IGRpc2N1c3Npbmcg d2hldGhlciB0aGV5IGNhbiBsaXZlIHdpdGggdGhhdC4gVGhleSBtYXkgZGVjaWRlIHRvIGp1c3Qg cmVmZXJlbmNlIHRoaW5ncyBhcyB0aGV5IHN0YW5kLiBJZiB0aGVpciBhbnN3ZXIgaW52b2x2ZXMg YSByZXF1ZXN0IHRvIHJlc3RydWN0dXJlIGFueXRoaW5nLCBJIHdpbGwgcHVsbCBpbiB0aGUgYXV0 aG9ycyBhbmQgTU1VU0lDL0lDRSBjaGFpcnMuDQo+PiANCj4+IFRoYW5rcyENCj4+IA0KPj4gQmVu Lg0KPj4gDQoNCg== From nobody Wed Apr 18 00:17:08 2018 Return-Path: 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 0278E12D7F5 for ; Wed, 18 Apr 2018 00:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 3qElVbynMzj0 for ; Wed, 18 Apr 2018 00:17:05 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C62126B6D for ; Wed, 18 Apr 2018 00:17:05 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id 203so427971vka.12 for ; Wed, 18 Apr 2018 00:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2O1x3GdKZcHNBB3XeRWgvHII/y4gtCee+67I+QvFAMY=; b=IKL9R05ZJ2oqSH74YCfIuPWu+BoPvXCS+mZ8eq4qeZRbdaOQoWQeHpDj4qHTNiIaMH an12GEUEYZfZM0gnADTR9F2wTIcDj+/28/bfDAR7+DfHDpjsAsUb5ZEgkeumzdvZhEVI LPIsOM/tFwr9c+bOI7puu/ZZDF5pd1C3HHWLIm6RhTZus4XJN1aazAa1YfznvjICfaQZ FHt72xYg3DRfJXVkfsi322Fdrxp7SrOL+ChBBsjvm75YRv9rDG9uF/qswGef/8lB5Q+f zaob5fHmeBjHOzg2OZB0W7klvsYLvhLSZhcsk7AckUMKK7eu1iisfj98wnl+MjBk2aF2 m32w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2O1x3GdKZcHNBB3XeRWgvHII/y4gtCee+67I+QvFAMY=; b=Kb+eK8CALqqcDAz5Vz5y1gNCKuwR/iyEnRoIvGHSSqBl5yNxHIyPuGGeiVeGlud2dz JF1F2qlVRXVatJJvgGskhpsLEAX0e93xX0TEyLTeFc7wvpbC3IY/dhKcxvdFQmYO16Gj vRfwm+LjAPpl2of4N7CfeubALb/+BoO6re9P7iVOGlbAOWhGqBdJ6rTsj+8LeAWSXLwA VT1+GEFOTiu8gOYxHWaj3Zi5tHMW2jCNyPYzYFMtxUfRgG5WKhH23lneeqLRXREuRmrw vEvSCuya9QvKWiDk/VegUZ6KqUP6tIhpLhmbu6WCjOG9Hj1LrqdJ8TDPaPCjmXzQQw3b 9L/w== X-Gm-Message-State: ALQs6tBXhdta3IpfXwboiOV9C1tnouxb0RIFPSJtJnFSZtoilgi2IxB4 R/Qt7HwVi7I97yzesDiwvImRxO0mAy4IgnCtpPmEIAv9lSY= X-Google-Smtp-Source: AIpwx49mXqZPhZWtr/3YFGVnths5QH/cebV/ubU2qQPWdTavLN5rt/ePVoWeSKYgUBB5+Rr19hhFwW6QNyKeGY/JqzY= X-Received: by 10.31.157.216 with SMTP id g207mr554634vke.111.1524035824186; Wed, 18 Apr 2018 00:17:04 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> In-Reply-To: <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> From: Justin Uberti Date: Wed, 18 Apr 2018 07:16:53 +0000 Message-ID: To: Tim Panton Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="001a11427634edb1ba056a1a3db0" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 07:17:08 -0000 --001a11427634edb1ba056a1a3db0 Content-Type: text/plain; charset="UTF-8" OK, merged b) via https://github.com/juberti/draughts/pull/98. Sean, should I produce a new version of the document? On Tue, Apr 17, 2018 at 5:40 AM westhawk wrote: > > > On 16 Apr 2018, at 23:06, Justin Uberti < > juberti=40google.com@dmarc.ietf.org> wrote: > > Here's a specific and minimal proposal, which is a slight modification of Sean's > proposal in https://github.com/juberti/draughts/pull/98/files: > > *The details of this consent are left to the implementation; one potential > mechanism is to tie this consent to getUserMedia consent. Alternatively > implementations can provide a specific mechanism to obtain user consent > where needed, e.g., when a VPN is in use.* > > b) Sean's proposal (without the boldface) > > > b) > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11427634edb1ba056a1a3db0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, merged b) via=C2=A0https://github.com/juberti/draughts/pull/98.
<= br>
Sean, should I produce a new version of the document?

On Tue, Apr 17, 2018 at= 5:40 AM westhawk <thp@westhawk.co= .uk> wrote:


On 16 Apr 2018, at 23:06, Justin Uberti <juberti=3D40g= oogle.com@dmarc.ietf.org> wrote:

Here's a spec= ific and minimal proposal, which is a slight modification of=C2=A0Sean's proposal in=C2=A0https://github.com/juberti/draug= hts/pull/98/files:

The details of this consent are left to the implementation; one po= tential mechanism is to tie this consent to getUserMedia consent.=C2=A0Alte= rnatively implementations can provide a specific mechanism to obtain user c= onsent where needed, e.g., when a VPN is in use.
<= br>
b) Sean's proposal (without the boldface)

b)

___________________________= ____________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--001a11427634edb1ba056a1a3db0-- From nobody Wed Apr 18 13:20:15 2018 Return-Path: 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 0600C126DFB for ; Wed, 18 Apr 2018 13:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 rWHM9UxiR6F0 for ; Wed, 18 Apr 2018 13:20:11 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F8212DA42 for ; Wed, 18 Apr 2018 13:20:07 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id f20-v6so3188638qtp.7 for ; Wed, 18 Apr 2018 13:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mm7GnRMia6FfXd/VOTyLLOmlVUy59yeN8iL3driZsho=; b=XdEOnTcECOXHNf/SfbXTx6879mZSOpDO/YxP6TUoqO1DJPl7dCu4PIlZHGac0SVbLP XTFqHspzLIA7GNU6j3yxNM9/CQllG6yc83F7iynxe+afMM88OxvBI58H8OSIZDwBxYKs U3OZLTsWxqm00gmosh/APr4Csm3v6Hy/CYYn0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mm7GnRMia6FfXd/VOTyLLOmlVUy59yeN8iL3driZsho=; b=FJn4pwpXwqbz3C0yyEWmGFs35Aj3EjVATR08aWuzdceLbh2fR+q4abaU4DZ5diqRNj io7MlppRVSLnK0ctP6lFuTYJUgkqA7kOhmylM1XWcIgwP9fz3qUQCgTYaCXMxfnco/BF 2Gxg37L/cGsLjJ/Uhj2BC2Utwo9WIK1pv2THtejq2BShXb9s12lJQIlJZYs1hJw2INDH +UwgX2QZ6UmczuPuiiX42yA3ezeO6YmYWuNiq23+rdhSOK6HZKp9YPw1Q+v9W4D0zyew h+ZSDkIzo67Pa4tHp3sD6yKEB4ygrz8k7v2M7IThPUzzE+eLs6rOUs0TRFZh4/xKL2iZ 2CTA== X-Gm-Message-State: ALQs6tCTZgaLvQv6e5+BisdyODnAkPISQjUfpYgYPZGaBRznUBGhKKWQ F6Ca5Ga9l9KG8OfIWhwrJhlIZQ== X-Google-Smtp-Source: AB8JxZos+eXBbNjxkgoRDA/zNGt0xFj3SsRnrbnqkjwficGsTnnh4qPlXS0ls781UgtVevSoJWEFcg== X-Received: by 2002:aed:21a7:: with SMTP id l36-v6mr3347450qtc.265.1524082806060; Wed, 18 Apr 2018 13:20:06 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id a28sm1522698qkj.28.2018.04.18.13.20.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 13:20:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: Date: Wed, 18 Apr 2018 16:20:03 -0400 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> To: Justin Uberti X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 20:20:14 -0000 Yes please. I think the IETF LC should be on the latest text. Note I=E2=80=99ve already updated the Shepherd write-up as Stephen = suggested. spt > On Apr 18, 2018, at 03:16, Justin Uberti = wrote: >=20 > OK, merged b) via https://github.com/juberti/draughts/pull/98. >=20 > Sean, should I produce a new version of the document? >=20 > On Tue, Apr 17, 2018 at 5:40 AM westhawk wrote: >=20 >=20 >> On 16 Apr 2018, at 23:06, Justin Uberti = wrote: >>=20 >> Here's a specific and minimal proposal, which is a slight = modification of Sean's proposal in = https://github.com/juberti/draughts/pull/98/files: >>=20 >> The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use. >>=20 >> b) Sean's proposal (without the boldface) >=20 > b) >=20 > _______________________________________________ > 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 From nobody Wed Apr 18 13:20:29 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F5112D960 for ; Wed, 18 Apr 2018 13:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524082820; bh=W1Cmu/JwRgGPdOccqG6jFIdJgcZsXBGIIx8uIDQ7PLQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=tIoOCJAEuzGCoUUIwTZQYVlZHSiw3PS92xPJd8tCZdxkjQgY2wxttCZW0s06Z/t5f QU9pejb1JMcgrBadLv+O1Nad5d0SmIpYc17F+YbjKi0LPeWiQZ5fwnWCLn2zj6ZkDR u2nqcDU424ukO7JKL/TQuB/QgMkogjX+3LucT9+w= X-Mailbox-Line: From sean@sn3rd.com Wed Apr 18 13:20:17 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE70D12DA03 for ; Wed, 18 Apr 2018 13:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524082817; bh=W1Cmu/JwRgGPdOccqG6jFIdJgcZsXBGIIx8uIDQ7PLQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Dwbn03hM78Hk4rJXpc7EjLenD7k0PwxXL3XpDxS5W2Wk7noybp8rcoF2QF3vwy3od ANNxIkr9hzzTFrwz4nyxSNVgVQBqms6Scb2v5pcp6eciyCQEUCWzwL8ibRXtUYKRDg RMLW1XuamIvbfKPXcDqOiNsmim5DimYRomgXtcsw= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEEE12D948 for ; Wed, 18 Apr 2018 13:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 Ni2QqvXUV1WW for ; Wed, 18 Apr 2018 13:20:14 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F5712E05D for ; Wed, 18 Apr 2018 13:20:07 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id j3-v6so3193384qtn.9 for ; Wed, 18 Apr 2018 13:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mm7GnRMia6FfXd/VOTyLLOmlVUy59yeN8iL3driZsho=; b=XdEOnTcECOXHNf/SfbXTx6879mZSOpDO/YxP6TUoqO1DJPl7dCu4PIlZHGac0SVbLP XTFqHspzLIA7GNU6j3yxNM9/CQllG6yc83F7iynxe+afMM88OxvBI58H8OSIZDwBxYKs U3OZLTsWxqm00gmosh/APr4Csm3v6Hy/CYYn0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mm7GnRMia6FfXd/VOTyLLOmlVUy59yeN8iL3driZsho=; b=RYnjS+yBaxuNjmheVOMerfXD8aL2Mk4sVd6azpg8KINbuk6NLMSyhj1AF3dX71VPmZ Te/eBsOpzMQU/DUoDY5hOJtzkuTZr7VURmGYHrQoiNG/uPkcfIka0CTJH4fwptyDMqhz jXX7BcVY8yrK/84q6DFMnznDaNFh058mxNDCzG+st9bGZp+DEC7STHXOi+ZAP1Ghvfbm ak9fMXdy32bZq1bjbCf5pegDcpGIol/zB25/+YqynvjwVQqGkRsnCTh9L6tvRPnZFnfJ IwqIhCysIcf/DiPl5D08K0McntjZ7PeB2B+GfBXqnCbNk6RuHxD9xJoqj2PmQHmcylsY UzQA== X-Gm-Message-State: ALQs6tD4xEq3hN0fAZqI5iLJ7mp1x44EePQmf3NC80zfaHdprVCRnhb9 EbzocyM9NflRnrYUUHzyXbPJLnvwv/Q= X-Google-Smtp-Source: AB8JxZos+eXBbNjxkgoRDA/zNGt0xFj3SsRnrbnqkjwficGsTnnh4qPlXS0ls781UgtVevSoJWEFcg== X-Received: by 2002:aed:21a7:: with SMTP id l36-v6mr3347450qtc.265.1524082806060; Wed, 18 Apr 2018 13:20:06 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id a28sm1522698qkj.28.2018.04.18.13.20.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 13:20:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: Date: Wed, 18 Apr 2018 16:20:03 -0400 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.6.18) To: Justin Uberti Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 20:20:23 -0000 Yes please. I think the IETF LC should be on the latest text. Note I=E2=80=99ve already updated the Shepherd write-up as Stephen = suggested. spt > On Apr 18, 2018, at 03:16, Justin Uberti = wrote: >=20 > OK, merged b) via https://github.com/juberti/draughts/pull/98. >=20 > Sean, should I produce a new version of the document? >=20 > On Tue, Apr 17, 2018 at 5:40 AM westhawk wrote: >=20 >=20 >> On 16 Apr 2018, at 23:06, Justin Uberti = wrote: >>=20 >> Here's a specific and minimal proposal, which is a slight = modification of Sean's proposal in = https://github.com/juberti/draughts/pull/98/files: >>=20 >> The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use. >>=20 >> b) Sean's proposal (without the boldface) >=20 > b) >=20 > _______________________________________________ > 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 From nobody Wed Apr 18 14:06:00 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9EF126C3D; Wed, 18 Apr 2018 14:05:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152408555412.29638.11166277791311126634@ietfa.amsl.com> Date: Wed, 18 Apr 2018 14:05:54 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 21:05:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC IP Address Handling Requirements Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-07.txt Pages : 11 Date : 2018-04-18 Abstract: This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-07 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 18 14:08:55 2018 Return-Path: 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 341F8126CD6 for ; Wed, 18 Apr 2018 14:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 2kF9lNR-1-er for ; Wed, 18 Apr 2018 14:08:51 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C37C126C3D for ; Wed, 18 Apr 2018 14:08:51 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id r16so2075267uak.11 for ; Wed, 18 Apr 2018 14:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=csYP0mq7WIBEre8I6x3EqmGiAcE9EtY6Jc+5CIZI6u4=; b=ODFW97BwQ3cNJAuEw+oJD8RzcMwKbMZScLmVSegrw/M99Xsa2ZvhflRWhROxijEaJQ 7KMUxUK+Cnsw0IshC7qkAEp7jr7qqKSKiqONFdfZoEiDe6hjVOwxNBroFFX3KUj6rmgp +KDnU5kPNUEHngGxMmL3PB4rcaxu4LuLhp7lLJT6MoNSj59l8qb+lReFtygVYaRyN4NN Tz/n7gKWubo76SbNhwimnvDQHVNJSTTQwsONsq7pPVCPbvUHAUSoSbRrpnCKdbxPlYtV 17Rty0ttp4ebMGSxEQjyFq7xEna9xfnaCbOJZcqz/yzl+DgTlSrYRDgulUTt0/CBIOoU 9ytg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=csYP0mq7WIBEre8I6x3EqmGiAcE9EtY6Jc+5CIZI6u4=; b=U+TOLjESm9x7Kj8WrTzfaWJqaj2fK2pQHRysFfkkgKyzZylnt4DI3Y0Yntfs6Nn9dM sB2FVn+I0auIP/ffXoQbMs7t/E2IgO0e6tRD2YpXqTwvgOQ5j9qtuXS13qokKtt0KJry CHnLCtWVZkLgBWO2Xvk6Qc7dOPhmz9TVHZKJ9LspNuLxT4RxTGbIy8m6UaD+hnjqI542 mtdFVJL2q9D53VOqKaj4dWHZsAQbD54ZSKNW0A+sVlNPKYyQiWU2aWso1IZx8PR4bk6Z G2RvKCqVlJjEAXmHoRplMcCGQ46uehqOZrhhktLq9X9V/OdPiiPfiAN+KIXQNDEKT2cA guZQ== X-Gm-Message-State: ALQs6tDpnXarOJir9c10QVe5t3opJSg6z83X5mjbqvtL2msvsXjw3OCt JzZ2gqJMBaFK3dvlPOw0ct2L9EQfp4x1X+8fZKjnVQ== X-Google-Smtp-Source: AIpwx4+ZZXcaCRudCpaF4pfNzNPHdC8Z3KkNxLuJI0J5pera3XGnLjIgzoktHo2GLELshskMrr01cCTixxp+OWNuA4A= X-Received: by 10.176.75.131 with SMTP id v3mr2767032uaf.108.1524085730078; Wed, 18 Apr 2018 14:08:50 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> In-Reply-To: <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> From: Justin Uberti Date: Wed, 18 Apr 2018 21:08:39 +0000 Message-ID: To: Sean Turner Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="f4030436147c8d3742056a25dc6f" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 21:08:54 -0000 --f4030436147c8d3742056a25dc6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/07/ On Wed, Apr 18, 2018 at 1:20 PM Sean Turner wrote: > Yes please. I think the IETF LC should be on the latest text. > > Note I=E2=80=99ve already updated the Shepherd write-up as Stephen sugges= ted. > > spt > > > On Apr 18, 2018, at 03:16, Justin Uberti 40google.com@dmarc.ietf.org> wrote: > > > > OK, merged b) via https://github.com/juberti/draughts/pull/98. > > > > Sean, should I produce a new version of the document? > > > > On Tue, Apr 17, 2018 at 5:40 AM westhawk wrote: > > > > > >> On 16 Apr 2018, at 23:06, Justin Uberti 40google.com@dmarc.ietf.org> wrote: > >> > >> Here's a specific and minimal proposal, which is a slight modification > of Sean's proposal in https://github.com/juberti/draughts/pull/98/files: > >> > >> The details of this consent are left to the implementation; one > potential mechanism is to tie this consent to getUserMedia consent. > Alternatively implementations can provide a specific mechanism to obtain > user consent where needed, e.g., when a VPN is in use. > >> > >> b) Sean's proposal (without the boldface) > > > > b) > > > > _______________________________________________ > > 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 > --f4030436147c8d3742056a25dc6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=
On Wed, Apr 18, 2018 at 1:20 PM Sean Turner <sean@sn3rd.com> wrote:
=
Yes please.=C2=A0 I think the IETF LC = should be on the latest text.

Note I=E2=80=99ve already updated the Shepherd write-up as Stephen suggeste= d.

spt

> On Apr 18, 2018, at 03:16, Justin Uberti <juberti=3D40google.com@dmarc.ietf.o= rg> wrote:
>
> OK, merged b) via https://github.com/juberti/draught= s/pull/98.
>
> Sean, should I produce a new version of the document?
>
> On Tue, Apr 17, 2018 at 5:40 AM westhawk <thp@westhawk.co..uk> w= rote:
>
>
>> On 16 Apr 2018, at 23:06, Justin Uberti <juberti=3D40google.com@dmarc.iet= f.org> wrote:
>>
>> Here's a specific and minimal proposal, which is a slight modi= fication of Sean's proposal in https://github.c= om/juberti/draughts/pull/98/files:
>>
>> The details of this consent are left to the implementation; one po= tential mechanism is to tie this consent to getUserMedia consent. Alternati= vely implementations can provide a specific mechanism to obtain user consen= t where needed, e.g., when a VPN is in use.
>>
>> b) Sean's proposal (without the boldface)
>
> b)
>
> _______________________________________________
> 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
--f4030436147c8d3742056a25dc6f-- From nobody Thu Apr 19 09:22:46 2018 Return-Path: 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 6060F12D86E for ; Thu, 19 Apr 2018 09:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 DB27wfYT1clr for ; Thu, 19 Apr 2018 09:22:41 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319F81200E5 for ; Thu, 19 Apr 2018 09:22:41 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id z9so2878791pfe.6 for ; Thu, 19 Apr 2018 09:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dZ1jhw3obYD2ak7UATdbsr5zN+MXT2cI/0xWwdr11wM=; b=FELiThm2GqEL3ahxARtBa0PLXXhz5GaHu12F/wxCJMuM2EUVxZrHSflIdbhsuHsu6B +dnHLRgdQNY4pQTPwVJhWQjgwF9QZ/Mg19w2NtyFW9mvLuGxYXuRIgeNPtsuT0hJZdH6 QGlP2MvkFKWwMarc7ylk3TSbKMX1bpDu9C/cM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dZ1jhw3obYD2ak7UATdbsr5zN+MXT2cI/0xWwdr11wM=; b=SbGSSOJ9x70yGUQQ0lPPvojLOulGua+LwsH1c5vY1Tw3zj8Y1J1VdiBDM5iFG73Bbc Wx/XZI/Vv224ROTncZWC7dha7butl3dGyM6SI9xQtwTXpfMdwJVtk2wvFWGjcFxGx/Fy NGyhBL/tY6LEbEhcI1LuFHEqml1pt/Zvg3diLXKQXYmO5iBt8conj1Ip1wEWnLN52gsK F37WdI9cAWU/ODaEN5VRrRFFaUyw0NL0zFoVf1QP6FZ8eCQbEnKIChSkHnWy0VX18mlB OzJQ+XJkwHewuf4CmKH55oBd55xVdg/TdB4ZaRB2MCdwNlnu5ixloJk6KGSqv6a+WX6e JLFQ== X-Gm-Message-State: ALQs6tBa+G3jdrBFBmRSrLCKdTepkvyL1MDUbYiivwr/WGJfPxrp5EKG AxM3XaOe82ytzHI/IVO7rL7Fu+OQ6dQ= X-Google-Smtp-Source: AIpwx4/+c3bp+svIxIVNKKRJDvvaReDba3Nu4k9egR1g2xJtYY1r7+nKduiJrgl3BLj6+pGGrXBLPQ== X-Received: by 10.98.62.87 with SMTP id l84mr6356945pfa.135.1524154960539; Thu, 19 Apr 2018 09:22:40 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:3c31:4841:48d8:a161? ([2601:647:4600:3f31:3c31:4841:48d8:a161]) by smtp.gmail.com with ESMTPSA id b193sm5021618pga.7.2018.04.19.09.22.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 09:22:38 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_85AFA3A7-D18E-485D-A6D6-632EE842DCE2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 19 Apr 2018 09:22:36 -0700 In-Reply-To: Cc: Sean Turner , RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 16:22:44 -0000 --Apple-Mail=_85AFA3A7-D18E-485D-A6D6-632EE842DCE2 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E500D1F-CB31-4BFD-A4BB-66685948AA72" --Apple-Mail=_6E500D1F-CB31-4BFD-A4BB-66685948AA72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 While I understand the arguments against adding more mode I still think = the paragraph describing Mode 4 is missing details and causes confusion = among implementers: - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HTTP = proxy or a TURN server. This can easily be improved by replacing the word =E2=80=9Cproxy=E2=80=9D = with =E2=80=9CHTTP proxy=E2=80=9D everywhere in the Mode 4 paragraph. - It is unclear how an implementation should behave in the absence of = such a proxy. I would suggest to add a sentence the implementation should not hand out = any candidates in the absence of a HTTP proxy. Best regards Nils Ohlmeier > On Apr 18, 2018, at 14:08, Justin Uberti = wrote: >=20 > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/07/ = >=20 > On Wed, Apr 18, 2018 at 1:20 PM Sean Turner > wrote: > Yes please. I think the IETF LC should be on the latest text. >=20 > Note I=E2=80=99ve already updated the Shepherd write-up as Stephen = suggested. >=20 > spt >=20 > > On Apr 18, 2018, at 03:16, Justin Uberti = > wrote: > > > > OK, merged b) via https://github.com/juberti/draughts/pull/98 = . > > > > Sean, should I produce a new version of the document? > > > > On Tue, Apr 17, 2018 at 5:40 AM westhawk = wrote: > > > > > >> On 16 Apr 2018, at 23:06, Justin Uberti = > wrote: > >> > >> Here's a specific and minimal proposal, which is a slight = modification of Sean's proposal in = https://github.com/juberti/draughts/pull/98/files = : > >> > >> The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use. > >> > >> b) Sean's proposal (without the boldface) > > > > b) > > > > _______________________________________________ > > 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 = >=20 > _______________________________________________ > 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 --Apple-Mail=_6E500D1F-CB31-4BFD-A4BB-66685948AA72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 While= I understand the arguments against adding more mode I still think the = paragraph describing Mode 4 is missing details and causes confusion = among implementers:

- = It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HTTP = proxy or a TURN server.

This can easily be improved by replacing the word = =E2=80=9Cproxy=E2=80=9D with =E2=80=9CHTTP proxy=E2=80=9D everywhere in = the Mode 4 paragraph.

- It is unclear how an implementation should behave in the = absence of such a proxy.

I would suggest to add a sentence the = implementation should not hand out any candidates in the absence of a = HTTP proxy.

Best = regards
  Nils Ohlmeier

On Apr 18, 2018, at 14:08, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/= 07/

On Wed, Apr 18, 2018 at 1:20 PM Sean Turner = <sean@sn3rd.com> wrote:
Yes please.  I think the IETF LC should be = on the latest text.

Note I=E2=80=99ve already updated the Shepherd write-up as Stephen = suggested.

spt

> On Apr 18, 2018, at 03:16, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
>
> OK, merged b) via https://github.com/juberti/draughts/pull/98.
= >
> Sean, should I produce a new version of the document?
>
> On Tue, Apr 17, 2018 at 5:40 AM westhawk <thp@westhawk.co..uk> = wrote:
>
>
>> On 16 Apr 2018, at 23:06, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
>>
>> Here's a specific and minimal proposal, which is a slight = modification of Sean's proposal in https://github.com/juberti/draughts/pull/98/files:
>>
>> The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use.
>>
>> b) Sean's proposal (without the boldface)
>
> b)
>
> _______________________________________________
> 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
=
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_6E500D1F-CB31-4BFD-A4BB-66685948AA72-- --Apple-Mail=_85AFA3A7-D18E-485D-A6D6-632EE842DCE2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrYwkwACgkQY2o/VmzJ +KGjGBAAzgzx+SCCOe8uf9XGuQBPizavMfvvse5FEWj2MjvCLKlrDVVpCmv0vv1L K0+GmSvHTGjWDHMMJnpflGv3qW7xMuS6y3k6ZzjJqk9io+YdZ+y0uwujh37zsqIh BeAND/dLcpSTCFjq82jK49ptTIt8XOUWzd3ToJu4AWkIn7q13YHAykP4ggOR/MX0 bLVECMy0r5QFI5keRfzh1HXvSZq4HTE98pZdNi25Jsd3SqnFMTN678PjjWpC/Abk jgrR07pUVRtuniBVhgPBV8Dee3SbZGj++mkgz47CAzMY4vNmASRMK/PA1XPVfrQU DAN2i/IUKsZ+lJyur6TyGnLQVELuzZTOz8vlYVsKFA93ecj9dqBSBXfFZ/hY7eHR lMPD2DpGM2IpHNLFGxHC5bvF5jKFtJEcZGNpMjo9O7/BHJLy1t6hs2Jt/WUPCcLm zS1maD6+h/ajT3/CJmUmhcnSH5HS/TUf5fmYNsRP6A3AGN0ZiGJylP/8OF+iWO8B ymlbmQBwkqiJNjfbPidEEoh51mDCEnZTfWj+sq4IE6OLCQRwVlk5TTHBuffY0LuJ O+cAdALtOXO+xn1jQyBh+9+dZDrWBCpvTBq95ZRKVOfvdngkz747TBE16F/Iuhz5 DHLkexfw9lAT3H9Gh2PoKX8KS8A21mLgXkcWRI791ZJKsTDAscg= =RcyO -----END PGP SIGNATURE----- --Apple-Mail=_85AFA3A7-D18E-485D-A6D6-632EE842DCE2-- From nobody Thu Apr 19 09:22:51 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A3A126E64 for ; Thu, 19 Apr 2018 09:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524154964; bh=D1PAww33KXgXkxqHKIpvKS5gGIDetoOFhqepYlqLCfA=; h=From:Subject:Date:In-Reply-To:Cc:References:To; b=EBpty7TQQ7PvoNMiwppCbwZHrR8ZpDn4+wbSb0VGlnK/+SyNYJ8k0w7bmjqM7JI4F ATGaz/WByT1elSizj1+Huf4ht51WknKDYaJeupBQ66k5BPB0pfFVeHzcOvZvqYKOLK gpQEiDOd9UdfQi1dt1dhkQL0EHmbTKKpdaNABYgk= X-Mailbox-Line: From nohlmeier@mozilla.com Thu Apr 19 09:22:44 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 803981200E5; Thu, 19 Apr 2018 09:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524154964; bh=D1PAww33KXgXkxqHKIpvKS5gGIDetoOFhqepYlqLCfA=; h=From:Subject:Date:In-Reply-To:Cc:References:To; b=EBpty7TQQ7PvoNMiwppCbwZHrR8ZpDn4+wbSb0VGlnK/+SyNYJ8k0w7bmjqM7JI4F ATGaz/WByT1elSizj1+Huf4ht51WknKDYaJeupBQ66k5BPB0pfFVeHzcOvZvqYKOLK gpQEiDOd9UdfQi1dt1dhkQL0EHmbTKKpdaNABYgk= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572EA127275 for ; Thu, 19 Apr 2018 09:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 6qTMTpf7Zqm5 for ; Thu, 19 Apr 2018 09:22:42 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC022126E64 for ; Thu, 19 Apr 2018 09:22:41 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id p15so2872020pff.11 for ; Thu, 19 Apr 2018 09:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dZ1jhw3obYD2ak7UATdbsr5zN+MXT2cI/0xWwdr11wM=; b=FELiThm2GqEL3ahxARtBa0PLXXhz5GaHu12F/wxCJMuM2EUVxZrHSflIdbhsuHsu6B +dnHLRgdQNY4pQTPwVJhWQjgwF9QZ/Mg19w2NtyFW9mvLuGxYXuRIgeNPtsuT0hJZdH6 QGlP2MvkFKWwMarc7ylk3TSbKMX1bpDu9C/cM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dZ1jhw3obYD2ak7UATdbsr5zN+MXT2cI/0xWwdr11wM=; b=iPZU6h29fhL6puTmF+priOj1Z3fA0JJO7yWwm8IUgW06ah+F3VHk+TIIm745CCFNSH n/H11VAocuePVlSZ0hrWn+cnlEuFe6E/0gDbTAoTZkuu54fxVmcW7+x9GzWL0nYILErp cE4P8SdGuKpAAEdIBAmZPHvP7YK2glZ0qCGp6OpzJEXfXbCGliRnTq7YwUQAcwlOa5kx 5iXPfEk5spoS+fF3W4pk+GQYet5xugV67RmSO8ZzqPxei+/Blwgkhp/XdPk0rohDQ8Ui 2fb+sF8omsLCA8p5i9IbyQUC3xNOlQdKiLF8VmzrwaV3vDrKNjOipX3YPNQ7Igo5aGbM IdGw== X-Gm-Message-State: ALQs6tB7oAfh6P+3OdL1mmgkFYvDJ0UV9rH56/5k0l5waJDgY6b5C9sZ 8KYVYnAkFWtiWhuajN3gDKAnzFiHmHI= X-Google-Smtp-Source: AIpwx4/+c3bp+svIxIVNKKRJDvvaReDba3Nu4k9egR1g2xJtYY1r7+nKduiJrgl3BLj6+pGGrXBLPQ== X-Received: by 10.98.62.87 with SMTP id l84mr6356945pfa.135.1524154960539; Thu, 19 Apr 2018 09:22:40 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:3c31:4841:48d8:a161? ([2601:647:4600:3f31:3c31:4841:48d8:a161]) by smtp.gmail.com with ESMTPSA id b193sm5021618pga.7.2018.04.19.09.22.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 09:22:38 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_85AFA3A7-D18E-485D-A6D6-632EE842DCE2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 19 Apr 2018 09:22:36 -0700 In-Reply-To: Cc: Sean Turner , RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) To: Justin Uberti Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 16:22:45 -0000 --Apple-Mail=_85AFA3A7-D18E-485D-A6D6-632EE842DCE2 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E500D1F-CB31-4BFD-A4BB-66685948AA72" --Apple-Mail=_6E500D1F-CB31-4BFD-A4BB-66685948AA72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 While I understand the arguments against adding more mode I still think = the paragraph describing Mode 4 is missing details and causes confusion = among implementers: - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HTTP = proxy or a TURN server. This can easily be improved by replacing the word =E2=80=9Cproxy=E2=80=9D = with =E2=80=9CHTTP proxy=E2=80=9D everywhere in the Mode 4 paragraph. - It is unclear how an implementation should behave in the absence of = such a proxy. I would suggest to add a sentence the implementation should not hand out = any candidates in the absence of a HTTP proxy. Best regards Nils Ohlmeier > On Apr 18, 2018, at 14:08, Justin Uberti = wrote: >=20 > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/07/ = >=20 > On Wed, Apr 18, 2018 at 1:20 PM Sean Turner > wrote: > Yes please. I think the IETF LC should be on the latest text. >=20 > Note I=E2=80=99ve already updated the Shepherd write-up as Stephen = suggested. >=20 > spt >=20 > > On Apr 18, 2018, at 03:16, Justin Uberti = > wrote: > > > > OK, merged b) via https://github.com/juberti/draughts/pull/98 = . > > > > Sean, should I produce a new version of the document? > > > > On Tue, Apr 17, 2018 at 5:40 AM westhawk = wrote: > > > > > >> On 16 Apr 2018, at 23:06, Justin Uberti = > wrote: > >> > >> Here's a specific and minimal proposal, which is a slight = modification of Sean's proposal in = https://github.com/juberti/draughts/pull/98/files = : > >> > >> The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use. > >> > >> b) Sean's proposal (without the boldface) > > > > b) > > > > _______________________________________________ > > 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 = >=20 > _______________________________________________ > 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 --Apple-Mail=_6E500D1F-CB31-4BFD-A4BB-66685948AA72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 While= I understand the arguments against adding more mode I still think the = paragraph describing Mode 4 is missing details and causes confusion = among implementers:

- = It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HTTP = proxy or a TURN server.

This can easily be improved by replacing the word = =E2=80=9Cproxy=E2=80=9D with =E2=80=9CHTTP proxy=E2=80=9D everywhere in = the Mode 4 paragraph.

- It is unclear how an implementation should behave in the = absence of such a proxy.

I would suggest to add a sentence the = implementation should not hand out any candidates in the absence of a = HTTP proxy.

Best = regards
  Nils Ohlmeier

On Apr 18, 2018, at 14:08, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/= 07/

On Wed, Apr 18, 2018 at 1:20 PM Sean Turner = <sean@sn3rd.com> wrote:
Yes please.  I think the IETF LC should be = on the latest text.

Note I=E2=80=99ve already updated the Shepherd write-up as Stephen = suggested.

spt

> On Apr 18, 2018, at 03:16, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
>
> OK, merged b) via https://github.com/juberti/draughts/pull/98.
= >
> Sean, should I produce a new version of the document?
>
> On Tue, Apr 17, 2018 at 5:40 AM westhawk <thp@westhawk.co..uk> = wrote:
>
>
>> On 16 Apr 2018, at 23:06, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
>>
>> Here's a specific and minimal proposal, which is a slight = modification of Sean's proposal in https://github.com/juberti/draughts/pull/98/files:
>>
>> The details of this consent are left to the implementation; one = potential mechanism is to tie this consent to getUserMedia consent. = Alternatively implementations can provide a specific mechanism to obtain = user consent where needed, e.g., when a VPN is in use.
>>
>> b) Sean's proposal (without the boldface)
>
> b)
>
> _______________________________________________
> 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
=
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_6E500D1F-CB31-4BFD-A4BB-66685948AA72-- --Apple-Mail=_85AFA3A7-D18E-485D-A6D6-632EE842DCE2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrYwkwACgkQY2o/VmzJ +KGjGBAAzgzx+SCCOe8uf9XGuQBPizavMfvvse5FEWj2MjvCLKlrDVVpCmv0vv1L K0+GmSvHTGjWDHMMJnpflGv3qW7xMuS6y3k6ZzjJqk9io+YdZ+y0uwujh37zsqIh BeAND/dLcpSTCFjq82jK49ptTIt8XOUWzd3ToJu4AWkIn7q13YHAykP4ggOR/MX0 bLVECMy0r5QFI5keRfzh1HXvSZq4HTE98pZdNi25Jsd3SqnFMTN678PjjWpC/Abk jgrR07pUVRtuniBVhgPBV8Dee3SbZGj++mkgz47CAzMY4vNmASRMK/PA1XPVfrQU DAN2i/IUKsZ+lJyur6TyGnLQVELuzZTOz8vlYVsKFA93ecj9dqBSBXfFZ/hY7eHR lMPD2DpGM2IpHNLFGxHC5bvF5jKFtJEcZGNpMjo9O7/BHJLy1t6hs2Jt/WUPCcLm zS1maD6+h/ajT3/CJmUmhcnSH5HS/TUf5fmYNsRP6A3AGN0ZiGJylP/8OF+iWO8B ymlbmQBwkqiJNjfbPidEEoh51mDCEnZTfWj+sq4IE6OLCQRwVlk5TTHBuffY0LuJ O+cAdALtOXO+xn1jQyBh+9+dZDrWBCpvTBq95ZRKVOfvdngkz747TBE16F/Iuhz5 DHLkexfw9lAT3H9Gh2PoKX8KS8A21mLgXkcWRI791ZJKsTDAscg= =RcyO -----END PGP SIGNATURE----- --Apple-Mail=_85AFA3A7-D18E-485D-A6D6-632EE842DCE2-- From nobody Thu Apr 19 16:29:20 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC8212E889 for ; Thu, 19 Apr 2018 16:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524180559; bh=wDUy6pIAoRA+rEQ6vRwd108+ygPe/u5JJ1t7/K+KS+E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:Cc; b=JF37yhVtlLA9pZM/Rwz9ZNVm8DaHkiBotn3NsxnbADZpbdGW6CUXET2PTFHT6Je9Y JlxXzoA+l/stvkeHu55NJa/gLgFPFZTtzTwgogQGiF6rIFhA0lkc+5PJ72veJQt6YA 2GapNZVqrAXLYhoGi4c/wAA50T74L8BJWo1X7aeY= X-Mailbox-Line: From juberti@google.com Thu Apr 19 16:29:19 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0912E050; Thu, 19 Apr 2018 16:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524180559; bh=wDUy6pIAoRA+rEQ6vRwd108+ygPe/u5JJ1t7/K+KS+E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:Cc; b=JF37yhVtlLA9pZM/Rwz9ZNVm8DaHkiBotn3NsxnbADZpbdGW6CUXET2PTFHT6Je9Y JlxXzoA+l/stvkeHu55NJa/gLgFPFZTtzTwgogQGiF6rIFhA0lkc+5PJ72veJQt6YA 2GapNZVqrAXLYhoGi4c/wAA50T74L8BJWo1X7aeY= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFD0126E01 for ; Thu, 19 Apr 2018 16:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 JlpnAep-hhYl for ; Thu, 19 Apr 2018 16:29:16 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FC4126CB6 for ; Thu, 19 Apr 2018 16:29:16 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id s15so4575755uae.10 for ; Thu, 19 Apr 2018 16:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wDUy6pIAoRA+rEQ6vRwd108+ygPe/u5JJ1t7/K+KS+E=; b=DRfjDsilNK9dpxvXtcMsvgC+Qfpl1wt4t8NLxWEcSWIAC1VJyfGuJw5CrzQU+L8e2M q0pqp2/01FZnkSOEtQSSqubEpDFGZf1t1ZvsqK1y/gp9wGwFHicUHSkdOOLnfLidyytu HRD4wir/Gm2CFlTa+ZDLq/oM5Ze+5MT04J9bu2PKYMD3igRtuMzDkv9T0EMzVY2K1Vi3 GU+MB49suS6qBYglxk4wd8HKULGYfYk3dDt/zGxk6sxc/aXmACzA0ZcJvsC+e5upeb4N eerET8phAi6chxVkUMlH7v82kaKTZnQGrGYleG7xxxfi2/E2LNaPyK+WuewuuBku6iaX 9RPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wDUy6pIAoRA+rEQ6vRwd108+ygPe/u5JJ1t7/K+KS+E=; b=BnKHEurO3TnBbzEvoj9nZlOa7YTCf04/5N97l/DFNC9BqcQZEqup5/yRWYZlKPTP67 U8f53zJQyg/IRQxfMqGY2RmyAXD6NRn1jwTHea6Eju8v+cI7Pt7jQaAZ261DP1KUBs3w qEOzUCTfy0eoqvYJnY9f8J2Nt8yX6T/R6R0GZL0i+qlaDay8sgCrAZugPnlqrEO4SGs3 RZawlHyyLSYdUkcWystxHUO/3n55M4CxubR5ufUq65gDZYoOn2r7DQefVC1OxK9UAfbA AlVw89aImIm6d5dKA9HfyHWNG4pWRRFg24wrNYTvWyHQRSD1QLuo+lfAWaK4qZVQEVxb S5XQ== X-Gm-Message-State: ALQs6tCiuVjczVOjvgbNLGGDp5rKrS21/dVPl17SFfY2mBDrRO2nGMEp Pf6MZ6G2qHYD+DjX3HjAA859ub+ZOJ7HP6MSkaH7xw== X-Google-Smtp-Source: AIpwx4+B8PTplXmJ/0ba0tlsl3X46Vi8Rlf9/PAZ/KHUG7aecykftvwJ0YZshs9EgL3hyuRfgUYgXgXA0LG4vkn9dvA= X-Received: by 10.176.95.93 with SMTP id z29mr6235948uah.87.1524180555092; Thu, 19 Apr 2018 16:29:15 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> In-Reply-To: From: Justin Uberti Date: Thu, 19 Apr 2018 23:29:04 +0000 Message-ID: To: Nils Ohlmeier Content-Type: multipart/alternative; boundary="f403045fe14c9005b7056a3bf0b3" Cc: juberti@google.com Cc: RTCWeb IETF Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:29:20 -0000 --f403045fe14c9005b7056a3bf0b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier wrote= : > While I understand the arguments against adding more mode I still think > the paragraph describing Mode 4 is missing details and causes confusion > among implementers: > > - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HTTP pr= oxy or a TURN > server. > > This can easily be improved by replacing the word =E2=80=9Cproxy=E2=80=9D= with =E2=80=9CHTTP > proxy=E2=80=9D everywhere in the Mode 4 paragraph. > The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or RETURN proxy (SOCKS is specifically noted in the para). > > - It is unclear how an implementation should behave in the absence of suc= h > a proxy. > > I would suggest to add a sentence the implementation should not hand out > any candidates in the absence of a HTTP proxy. > This is a fair point. However, my take is that the behavior should be the same as Mode 3 in this case, as the web server already sees the client IP. I could add a sentence to make this super clear. --f403045fe14c9005b7056a3bf0b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Apr 19, 2018 at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
While I understand the arguments against adding more mode I still think= the paragraph describing Mode 4 is missing details and causes confusion am= ong implementers:

- It is not clear if the word =E2=80= =9Cproxy=E2=80=9D refers to a HTTP proxy or a TURN server.

This can easily be improved by replacing the word =E2=80=9Cpr= oxy=E2=80=9D with =E2=80=9CHTTP proxy=E2=80=9D everywhere in the Mode 4 par= agraph.

The proxy doesn&#= 39;t need to be a HTTP proxy; it could be a SOCKS or RETURN proxy (SOCKS is= specifically noted in the para).=C2=A0

=
- It is unclear how an implementation should behave in the absen= ce of such a proxy.

I would suggest to add a = sentence the implementation should not hand out any candidates in the absen= ce of a HTTP proxy.

This = is a fair point. However, my take is that the behavior should be the same a= s Mode 3 in this case, as the web server already sees the client IP. I coul= d add a sentence to make this super clear.
--f403045fe14c9005b7056a3bf0b3-- From nobody Thu Apr 19 16:29:26 2018 Return-Path: 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 BEAB912E050 for ; Thu, 19 Apr 2018 16:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 h_2uSJRh3WK0 for ; Thu, 19 Apr 2018 16:29:16 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1138124D37 for ; Thu, 19 Apr 2018 16:29:16 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id j18so4573258uae.12 for ; Thu, 19 Apr 2018 16:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wDUy6pIAoRA+rEQ6vRwd108+ygPe/u5JJ1t7/K+KS+E=; b=DRfjDsilNK9dpxvXtcMsvgC+Qfpl1wt4t8NLxWEcSWIAC1VJyfGuJw5CrzQU+L8e2M q0pqp2/01FZnkSOEtQSSqubEpDFGZf1t1ZvsqK1y/gp9wGwFHicUHSkdOOLnfLidyytu HRD4wir/Gm2CFlTa+ZDLq/oM5Ze+5MT04J9bu2PKYMD3igRtuMzDkv9T0EMzVY2K1Vi3 GU+MB49suS6qBYglxk4wd8HKULGYfYk3dDt/zGxk6sxc/aXmACzA0ZcJvsC+e5upeb4N eerET8phAi6chxVkUMlH7v82kaKTZnQGrGYleG7xxxfi2/E2LNaPyK+WuewuuBku6iaX 9RPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wDUy6pIAoRA+rEQ6vRwd108+ygPe/u5JJ1t7/K+KS+E=; b=GMRH26ZTIm2qmdWHThcaq0tutJHhjsQuOyr2Geo8CI/41Zi9VRwphdPSb2smOMJ2L9 J0eaELHs5x9cn9NyJXf1jlddVkzbhv4p9MjhB/NM4f0oj7PHfxHbnk9mSQgNZ6tnYjWb 9eRzEvZoGVCsCuOFcYQgz4+E9Or4/cYnnl+kdEHZwhfmtJLjroDSiJFfVV5YCAMXr4w1 hBANpes6voQx4wieO2Cps98th7/mFYodLi9m8yrjUUX9IEbDSPaQl6Yq63LSuGl8vswo 5hQ0eEJ70jsx3pJLLKtFtTbrG9p4iU6tjLCLjgvo2VuybA037OGYQ3jNpn/lx96uiDob wAWQ== X-Gm-Message-State: ALQs6tBos9b26vyS4lOEgXFY4m/NSocLZca4iqsHwNu+8QEOnXGLBAmE hMUBd0lHCstHYlpdz1wN1wF38e1BUQE5jFrRI6By9/zo X-Google-Smtp-Source: AIpwx4+B8PTplXmJ/0ba0tlsl3X46Vi8Rlf9/PAZ/KHUG7aecykftvwJ0YZshs9EgL3hyuRfgUYgXgXA0LG4vkn9dvA= X-Received: by 10.176.95.93 with SMTP id z29mr6235948uah.87.1524180555092; Thu, 19 Apr 2018 16:29:15 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> In-Reply-To: From: Justin Uberti Date: Thu, 19 Apr 2018 23:29:04 +0000 Message-ID: To: Nils Ohlmeier Cc: juberti=40google.com@dmarc.ietf.org, RTCWeb IETF Content-Type: multipart/alternative; boundary="f403045fe14c9005b7056a3bf0b3" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:29:20 -0000 --f403045fe14c9005b7056a3bf0b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier wrote= : > While I understand the arguments against adding more mode I still think > the paragraph describing Mode 4 is missing details and causes confusion > among implementers: > > - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HTTP pr= oxy or a TURN > server. > > This can easily be improved by replacing the word =E2=80=9Cproxy=E2=80=9D= with =E2=80=9CHTTP > proxy=E2=80=9D everywhere in the Mode 4 paragraph. > The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or RETURN proxy (SOCKS is specifically noted in the para). > > - It is unclear how an implementation should behave in the absence of suc= h > a proxy. > > I would suggest to add a sentence the implementation should not hand out > any candidates in the absence of a HTTP proxy. > This is a fair point. However, my take is that the behavior should be the same as Mode 3 in this case, as the web server already sees the client IP. I could add a sentence to make this super clear. --f403045fe14c9005b7056a3bf0b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Apr 19, 2018 at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
While I understand the arguments against adding more mode I still think= the paragraph describing Mode 4 is missing details and causes confusion am= ong implementers:

- It is not clear if the word =E2=80= =9Cproxy=E2=80=9D refers to a HTTP proxy or a TURN server.

This can easily be improved by replacing the word =E2=80=9Cpr= oxy=E2=80=9D with =E2=80=9CHTTP proxy=E2=80=9D everywhere in the Mode 4 par= agraph.

The proxy doesn&#= 39;t need to be a HTTP proxy; it could be a SOCKS or RETURN proxy (SOCKS is= specifically noted in the para).=C2=A0

=
- It is unclear how an implementation should behave in the absen= ce of such a proxy.

I would suggest to add a = sentence the implementation should not hand out any candidates in the absen= ce of a HTTP proxy.

This = is a fair point. However, my take is that the behavior should be the same a= s Mode 3 in this case, as the web server already sees the client IP. I coul= d add a sentence to make this super clear.
--f403045fe14c9005b7056a3bf0b3-- From nobody Thu Apr 19 16:34:31 2018 Return-Path: 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 42845126D0C for ; Thu, 19 Apr 2018 16:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 3IQnBjHK6UPg for ; Thu, 19 Apr 2018 16:34:27 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3568126CE8 for ; Thu, 19 Apr 2018 16:34:27 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id bj1-v6so4148558plb.8 for ; Thu, 19 Apr 2018 16:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CS1sE5pJ00hEONFjXgEFa2rDgh7iuORLYUXssIqrH8o=; b=TJvtVH/GnsPXhNLlSK2W1wvWVsLF1YkbL0QKEDwRo8tO2xVaA1R421VyGC+i+lm9FE kYnbAdHtEouevKyCU2fjOksDzrmJF1JddAhF07CpKZIbgsOso9Z7/V69nwUHu8o6YEsT 9Sgv86OTzgKXCALpaB7grtBn5vUos0gha+2Dc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CS1sE5pJ00hEONFjXgEFa2rDgh7iuORLYUXssIqrH8o=; b=p0UKq2TO6TA9YTpomrN32S/1FfXhBvPDhSURCfNwph4DMyi1wSA4LYEbpx7cHz+Msu ZWzrILW69UalXEP2mI6J15C13jV70Fyd5BvEJGrUtCDt7j7rwBcWClq0BjFagydVCE9a b1qJqZfa3og7Y0F/FyOgq5q1RfALaE7FBOoeRLq1STuF2F56MhoIfQoBNmJ3EQANd5kt eRZ5rr4uccpTtURSfptLEJQBf7LZP8U6YgBFkukM3ZlxyIgvOpBYqCd6lytyKFOWedRz btDqAFCDn8V5Bot3bTlEl4IC+EpnINATpLF4Zoi6N4xnudTTt7vOKZpsDb5O5Bl2n9yr xAqw== X-Gm-Message-State: ALQs6tDNVFN+Kkan0y/5Wu7laqkH6YJ5yED1SzrEGrXyMg7zsWhVhafX vAdYlEeg6Er2dtVt9i7w8VqY/Q== X-Google-Smtp-Source: AIpwx4+J50QdV/CgBGHohlN3DzFtvIRpwYPa9zDsnj/5TCZ7Bj6l8nTiVTNGNYsjLgN+haDLG8wC9w== X-Received: by 2002:a17:902:6709:: with SMTP id f9-v6mr7768108plk.159.1524180867111; Thu, 19 Apr 2018 16:34:27 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:3c31:4841:48d8:a161? ([2601:647:4600:3f31:3c31:4841:48d8:a161]) by smtp.gmail.com with ESMTPSA id r16sm11452179pff.123.2018.04.19.16.34.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 16:34:26 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AA459D82-3B35-45C7-A773-7BF5CEBD9E86"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 19 Apr 2018 16:34:24 -0700 In-Reply-To: Cc: juberti=40google.com@dmarc.ietf.org, RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:34:30 -0000 --Apple-Mail=_AA459D82-3B35-45C7-A773-7BF5CEBD9E86 Content-Type: multipart/alternative; boundary="Apple-Mail=_F092670B-1756-4DDE-A684-57B03E3F4D6F" --Apple-Mail=_F092670B-1756-4DDE-A684-57B03E3F4D6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 19, 2018, at 16:29, Justin Uberti wrote: > On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier > wrote: > While I understand the arguments against adding more mode I still = think the paragraph describing Mode 4 is missing details and causes = confusion among implementers: >=20 > - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HTTP = proxy or a TURN server. >=20 > This can easily be improved by replacing the word =E2=80=9Cproxy=E2=80=9D= with =E2=80=9CHTTP proxy=E2=80=9D everywhere in the Mode 4 paragraph. >=20 > The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or = RETURN proxy (SOCKS is specifically noted in the para). Fair enough. >=20 > - It is unclear how an implementation should behave in the absence of = such a proxy. >=20 > I would suggest to add a sentence the implementation should not hand = out any candidates in the absence of a HTTP proxy. >=20 > This is a fair point. However, my take is that the behavior should be = the same as Mode 3 in this case, as the web server already sees the = client IP. I could add a sentence to make this super clear. I think that would help. Although I=E2=80=99m wondering if your assumption is correct here if the = user is using a tunneling VPN, e.g. IPSEC or something which is not just = a simple HTTP proxy. Then I could see in edge cases the HTTP traffic = tacking a different path then your STUN packets. But I think it=E2=80=99s = probably okay to ignore that edge case. Best Nils Ohlmeier --Apple-Mail=_F092670B-1756-4DDE-A684-57B03E3F4D6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Apr 19, 2018, at 16:29, Justin Uberti <juberti@google.com> = wrote:
On Thu, Apr 19, 2018 = at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
While I understand the arguments against adding more mode I = still think the paragraph describing Mode 4 is missing details and = causes confusion among implementers:

- It is not clear if the word = =E2=80=9Cproxy=E2=80=9D refers to a HTTP proxy or a TURN = server.

This can easily be improved by replacing the word =E2=80=9Cprox= y=E2=80=9D with =E2=80=9CHTTP proxy=E2=80=9D everywhere in the Mode 4 = paragraph.

The proxy doesn't need to be a HTTP = proxy; it could be a SOCKS or RETURN proxy (SOCKS is specifically noted = in the para).

Fair enough.


- It is = unclear how an implementation should behave in the absence of such a = proxy.

I would suggest to add a sentence the implementation should = not hand out any candidates in the absence of a HTTP = proxy.

This is a fair point. However, my take = is that the behavior should be the same as Mode 3 in this case, as the = web server already sees the client IP. I could add a sentence to make = this super clear.

I think that = would help.
Although I=E2=80=99m wondering if your = assumption is correct here if the user is using a tunneling VPN, e.g. = IPSEC or something which is not just a simple HTTP proxy. Then I could = see in edge cases the HTTP traffic tacking a different path then your = STUN packets. But I think it=E2=80=99s probably okay to ignore that edge = case.

Best
  Nils = Ohlmeier
= --Apple-Mail=_F092670B-1756-4DDE-A684-57B03E3F4D6F-- --Apple-Mail=_AA459D82-3B35-45C7-A773-7BF5CEBD9E86 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrZJ4AACgkQY2o/VmzJ +KEnxA//f9GhEsB1Y7MugWHkTwUi5qe39/DLi4LvctdaxLM0Qpzt3hX2fmuHRsVa w9bhKuGra6gYt+X0SfMcan5K14KXW7f9rUUttBpHqHIxHcODfmaPdVC0Re/fhscu XRu5tmY8904wTznhCD0eaYlAzkIKM+v5gjpBpOrNtZSGFp4QMVDk+6+y6RHY3a92 HAl4vqiPg0RJZY+3QQTlxN8WI7SDXO4jbmzas6dzod2WCA/rJM0ytOcwB8MA8zqi LolIXD3Nl0AflnPOzWST2ev2vt5HG+FfTHl1dzybArIoITDV3zNLDs2bZ42qwHOw oqy56Y84ek0ydVe4KpgrY4dt9+/6C2BlOHJktUK5RsaE+Oo7xl3mB3fxcGmSgUvK ZvS3hLBNZPTMOlXUFvwV2UQnS8z5TeiWqa8HgxTeqCmZ3OGqymkPc+fbdS+R9WMB 0rixlwkZNQF7SfVFZob+3T3opQwsQKMZbsfzeJh0sGy5ao74JSWwJhR5OH7qyBbG 0osyYw9icbzDxfhGKROLpUAB42GExmN4EhGQq7PIaUJFYqbFayZuhoOnzuiSdWgL NWWUsCYLzQVZiaYZjYIb7mMdloiSNytr4Da+hNURwii99tEj8Hd3sp2xqsToJlge cI6B0tOA+Rdq7Vt/a/V4MvbfzZzKT32lRFzSV4TCmdPEEU0zyF4= =H+SF -----END PGP SIGNATURE----- --Apple-Mail=_AA459D82-3B35-45C7-A773-7BF5CEBD9E86-- From nobody Thu Apr 19 16:34:46 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A97F126D0C for ; Thu, 19 Apr 2018 16:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524180871; bh=xFW2ugSdzfGSqIFtEZmsukJF1O0JzSOaRa52tV9QyTw=; h=From:Subject:Date:In-Reply-To:To:References:Cc:Cc; b=q+XBKXTBrU7aqR/c2lIIfk/OHIUkrj/gAhstL/P/2OrG/0RjrfoSL3qr0aT6Jbw3k hhw3YhBjzs/MyUrgyfN8BOJ5bElf86cAYRNoOcAyQBJEkEuNWK6fr2+HGsL9PJzE0v 5ekSGYssYezHaw0ddTGkZsg+6ES1r40CaDYxn/I8= X-Mailbox-Line: From nohlmeier@mozilla.com Thu Apr 19 16:34:31 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51386126CF6; Thu, 19 Apr 2018 16:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1524180871; bh=p8wTPLzd3wHI941khdA1rxeSf2eY4CavnqCpNuVV21E=; h=From:Subject:Date:In-Reply-To:To:References:Cc:Cc; b=bSuxqXdV8yO6vKBGv9aQoEiNBvk7oviK7FbbDmNiEXZic2AMBMexIGBtpfTyfCWc8 2XZTXGx9K4y65yrJ55xj30/oA8OLnnP2lum8iMOlZ0P7/HhTw9pzDCNbCYZycoK3QZ JgXeNEodt9aSXD5rTIHn1XKec6g72UTHMc2CQCMg= X-Original-To: dmarc-reverse@ietfa.amsl.com Delivered-To: dmarc-reverse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240A2126CE8 for ; Thu, 19 Apr 2018 16:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 xQ1_voiVnq0j for ; Thu, 19 Apr 2018 16:34:28 -0700 (PDT) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07C8126CF6 for ; Thu, 19 Apr 2018 16:34:27 -0700 (PDT) Received: by mail-pl0-x22a.google.com with SMTP id m7-v6so4158150plt.3 for ; Thu, 19 Apr 2018 16:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CS1sE5pJ00hEONFjXgEFa2rDgh7iuORLYUXssIqrH8o=; b=TJvtVH/GnsPXhNLlSK2W1wvWVsLF1YkbL0QKEDwRo8tO2xVaA1R421VyGC+i+lm9FE kYnbAdHtEouevKyCU2fjOksDzrmJF1JddAhF07CpKZIbgsOso9Z7/V69nwUHu8o6YEsT 9Sgv86OTzgKXCALpaB7grtBn5vUos0gha+2Dc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CS1sE5pJ00hEONFjXgEFa2rDgh7iuORLYUXssIqrH8o=; b=bVnUiUeYPGcVrSurvhEoDkylwviPwmur/ZqX59LQ2x+RZafQYKwTjklYwIaFiGCLy4 LFLBRz9w4JPS8/yUF8C0oull9NuS/tJxf9wBCJnYCUQ81NR+QxTV7aBojW+1YPdXRKdk 99tR9RmH8DbaqA2u7mIRHNaNTSRbd63g0MKoZFO7m44QFlmRV7t+uR1Vj8d92n+xoYHc TcHS1yyRyx5sCYBrcQE+woF3KlzAxJFfI+3Dn3YYkRmF+ZO7ABszfUoDB9KEV88fZuzO BPwd/sYhlF5Vy0GWtTZAd22sAkrCTET8A3uu7fA5+FDc3Ix2+iorOHhBUIX5mCN00iHe irnA== X-Gm-Message-State: ALQs6tB3n94y+qQu8xClisjUJ2h8KbefVZTCdCwIxeFpOkqyCMIepVX3 xJ5RXG5S0MQrvpLeLEgN+2az1A== X-Google-Smtp-Source: AIpwx4+J50QdV/CgBGHohlN3DzFtvIRpwYPa9zDsnj/5TCZ7Bj6l8nTiVTNGNYsjLgN+haDLG8wC9w== X-Received: by 2002:a17:902:6709:: with SMTP id f9-v6mr7768108plk.159.1524180867111; Thu, 19 Apr 2018 16:34:27 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:3c31:4841:48d8:a161? ([2601:647:4600:3f31:3c31:4841:48d8:a161]) by smtp.gmail.com with ESMTPSA id r16sm11452179pff.123.2018.04.19.16.34.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 16:34:26 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AA459D82-3B35-45C7-A773-7BF5CEBD9E86"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 19 Apr 2018 16:34:24 -0700 In-Reply-To: To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <20180412144158.44733ac7@lminiero> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Cc: juberti@google.com Cc: RTCWeb IETF Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:34:32 -0000 --Apple-Mail=_AA459D82-3B35-45C7-A773-7BF5CEBD9E86 Content-Type: multipart/alternative; boundary="Apple-Mail=_F092670B-1756-4DDE-A684-57B03E3F4D6F" --Apple-Mail=_F092670B-1756-4DDE-A684-57B03E3F4D6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 19, 2018, at 16:29, Justin Uberti wrote: > On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier > wrote: > While I understand the arguments against adding more mode I still = think the paragraph describing Mode 4 is missing details and causes = confusion among implementers: >=20 > - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HTTP = proxy or a TURN server. >=20 > This can easily be improved by replacing the word =E2=80=9Cproxy=E2=80=9D= with =E2=80=9CHTTP proxy=E2=80=9D everywhere in the Mode 4 paragraph. >=20 > The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or = RETURN proxy (SOCKS is specifically noted in the para). Fair enough. >=20 > - It is unclear how an implementation should behave in the absence of = such a proxy. >=20 > I would suggest to add a sentence the implementation should not hand = out any candidates in the absence of a HTTP proxy. >=20 > This is a fair point. However, my take is that the behavior should be = the same as Mode 3 in this case, as the web server already sees the = client IP. I could add a sentence to make this super clear. I think that would help. Although I=E2=80=99m wondering if your assumption is correct here if the = user is using a tunneling VPN, e.g. IPSEC or something which is not just = a simple HTTP proxy. Then I could see in edge cases the HTTP traffic = tacking a different path then your STUN packets. But I think it=E2=80=99s = probably okay to ignore that edge case. Best Nils Ohlmeier --Apple-Mail=_F092670B-1756-4DDE-A684-57B03E3F4D6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Apr 19, 2018, at 16:29, Justin Uberti <juberti@google.com> = wrote:
On Thu, Apr 19, 2018 = at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
While I understand the arguments against adding more mode I = still think the paragraph describing Mode 4 is missing details and = causes confusion among implementers:

- It is not clear if the word = =E2=80=9Cproxy=E2=80=9D refers to a HTTP proxy or a TURN = server.

This can easily be improved by replacing the word =E2=80=9Cprox= y=E2=80=9D with =E2=80=9CHTTP proxy=E2=80=9D everywhere in the Mode 4 = paragraph.

The proxy doesn't need to be a HTTP = proxy; it could be a SOCKS or RETURN proxy (SOCKS is specifically noted = in the para).

Fair enough.


- It is = unclear how an implementation should behave in the absence of such a = proxy.

I would suggest to add a sentence the implementation should = not hand out any candidates in the absence of a HTTP = proxy.

This is a fair point. However, my take = is that the behavior should be the same as Mode 3 in this case, as the = web server already sees the client IP. I could add a sentence to make = this super clear.

I think that = would help.
Although I=E2=80=99m wondering if your = assumption is correct here if the user is using a tunneling VPN, e.g. = IPSEC or something which is not just a simple HTTP proxy. Then I could = see in edge cases the HTTP traffic tacking a different path then your = STUN packets. But I think it=E2=80=99s probably okay to ignore that edge = case.

Best
  Nils = Ohlmeier
= --Apple-Mail=_F092670B-1756-4DDE-A684-57B03E3F4D6F-- --Apple-Mail=_AA459D82-3B35-45C7-A773-7BF5CEBD9E86 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrZJ4AACgkQY2o/VmzJ +KEnxA//f9GhEsB1Y7MugWHkTwUi5qe39/DLi4LvctdaxLM0Qpzt3hX2fmuHRsVa w9bhKuGra6gYt+X0SfMcan5K14KXW7f9rUUttBpHqHIxHcODfmaPdVC0Re/fhscu XRu5tmY8904wTznhCD0eaYlAzkIKM+v5gjpBpOrNtZSGFp4QMVDk+6+y6RHY3a92 HAl4vqiPg0RJZY+3QQTlxN8WI7SDXO4jbmzas6dzod2WCA/rJM0ytOcwB8MA8zqi LolIXD3Nl0AflnPOzWST2ev2vt5HG+FfTHl1dzybArIoITDV3zNLDs2bZ42qwHOw oqy56Y84ek0ydVe4KpgrY4dt9+/6C2BlOHJktUK5RsaE+Oo7xl3mB3fxcGmSgUvK ZvS3hLBNZPTMOlXUFvwV2UQnS8z5TeiWqa8HgxTeqCmZ3OGqymkPc+fbdS+R9WMB 0rixlwkZNQF7SfVFZob+3T3opQwsQKMZbsfzeJh0sGy5ao74JSWwJhR5OH7qyBbG 0osyYw9icbzDxfhGKROLpUAB42GExmN4EhGQq7PIaUJFYqbFayZuhoOnzuiSdWgL NWWUsCYLzQVZiaYZjYIb7mMdloiSNytr4Da+hNURwii99tEj8Hd3sp2xqsToJlge cI6B0tOA+Rdq7Vt/a/V4MvbfzZzKT32lRFzSV4TCmdPEEU0zyF4= =H+SF -----END PGP SIGNATURE----- --Apple-Mail=_AA459D82-3B35-45C7-A773-7BF5CEBD9E86-- From nobody Thu Apr 19 16:41:04 2018 Return-Path: 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 3D93D126CF6 for ; Thu, 19 Apr 2018 16:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o8MOAClqINu2 for ; Thu, 19 Apr 2018 16:41:01 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00464126CE8 for ; Thu, 19 Apr 2018 16:41:00 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id d1-v6so18260493wrj.13 for ; Thu, 19 Apr 2018 16:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wjs2Mgm+TwpHEBiydI28yZUzzM9L9MKSvqJJh17UFYA=; b=cDzvLntOhW4gl53x2q3IFTyw1ZTeDgoQcquTulHmZKGQuqXPRkriFBRq/+vzndF45z ydnI2nChjGdwdOt9qR8J164kdQCjTzm6RFubaGpanHCxroBiGjqXQC+aEUiRaudjunif t95LiDgu2KZ5ddxVhhoH42XmdBYvT+EVSMHkp9u1N9GAv+iKwZaRVF4sn7Zxyovgaw+0 tGPt7Wfr+FtvByaV4V+TL7JMkUHiAtbw6L9L25d4hW1jQeaQcK7d/pS5CladtVOwvCri AvbRN9CsdaSPjnmgwL4xF0qhdsIfUinhhlQfsyGInKl8aVDHfhNAG0WOps96tlsg/tpD jkmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wjs2Mgm+TwpHEBiydI28yZUzzM9L9MKSvqJJh17UFYA=; b=A4bG4/ZqdmN74qKWs86TaMJcjfSBLI2WRdZ2TntLyiOpte1ehdwrqeiR9wz49bj/cb gFzk61BtMb4/omAbF/qLcVB1BwJF4ckqlqwKRGfQYVq7vyM7YzCLj+pRX3cdxRNKGhuj lV1jhX76QU8CwGwpXcMxIBq2T1EwCjVWHc53vvZb/aqpZ85evdX3meMe+TiNsrRJfjfW SdfgfXN+V3Gguziqnrg/BuseYa/cSQKgXuw3r3CLcdKRDGk2Sk6komkdBQlBmskwS0du jw39zh3Y/Hlc6ndYILnygghU/0VZXs/27iY1Hs59hApYWoMR6vFXntZdj8lfbs2MaRmJ h+6A== X-Gm-Message-State: ALQs6tA9TmSOyDScPV+m5AG6DaQKbdHHQHjJgJSnJIdEaWPn7hTi5yC+ h1mh5SmPyeYxoKqU9hYvQo8wtQ== X-Google-Smtp-Source: AIpwx49C9eAeqF7Ae2YCVzcA02ZJHtPx8p7OB3kd/jj7USSbtEtHDPhezP/jQO+BHXg62Ra3zgb3DA== X-Received: by 10.28.5.198 with SMTP id 189mr343472wmf.155.1524181259013; Thu, 19 Apr 2018 16:40:59 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:b4bb:a980:85e1:c6f9? (p200300CD6F24EB00B4BBA98085E1C6F9.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:b4bb:a980:85e1:c6f9]) by smtp.gmail.com with ESMTPSA id r200sm846595wmb.39.2018.04.19.16.40.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 16:40:58 -0700 (PDT) To: rtcweb@ietf.org References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: Date: Fri, 20 Apr 2018 01:40:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:41:03 -0000 On 20.04.2018 01:29, Justin Uberti wrote: > On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier wrote: > >> While I understand the arguments against adding more mode I still think >> the paragraph describing Mode 4 is missing details and causes confusion >> among implementers: >> >> - It is not clear if the word “proxy” refers to a HTTP proxy or a TURN >> server. >> >> This can easily be improved by replacing the word “proxy” with “HTTP >> proxy” everywhere in the Mode 4 paragraph. >> > > The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or RETURN > proxy (SOCKS is specifically noted in the para). > >> >> - It is unclear how an implementation should behave in the absence of such >> a proxy. >> >> I would suggest to add a sentence the implementation should not hand out >> any candidates in the absence of a HTTP proxy. >> > > This is a fair point. However, my take is that the behavior should be the > same as Mode 3 in this case, as the web server already sees the client IP. > I could add a sentence to make this super clear. The web server, yes. But not the other peer. I don't think we can assume trust towards the web server equals trust towards the other peer. I would agree with Nils that it shouldn't hand out any candidates in this case. Cheers Lennart From nobody Thu Apr 19 17:03:12 2018 Return-Path: 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 B6505126DED for ; Thu, 19 Apr 2018 17:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 aO2Sz9nKroXX for ; Thu, 19 Apr 2018 17:03:09 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F51F126CB6 for ; Thu, 19 Apr 2018 17:03:09 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id r16so4607310uak.11 for ; Thu, 19 Apr 2018 17:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a/P1YpUhSHF2aShxzSXp+nBBTK1awLJozmjOXShN2NU=; b=wUC6vFM+i8z0Nn3zgc7Z9+xjHiIvdCXHem3PuNNIG2CYkk9eQw4fHVuKwDETV1OgwZ Ezjhjp8qggPBH/47HZtinZ1weAN78oH8JgIUT2RZUDXLT5r9Ngz22k+IEsLPgy/l6jdj HEDzA2qjHa2iJztHD6JfYZIbQrHxMWIEckijAdVeRXdIG1l3oJYzU/X19yqJIQISGFTY DqE5tQxZJMqB1Y9wglUmERu1A00wQlJhMVOW5843ABOY5WClUDfFZBy8Jgq3bh/BVsfN wh3vS5yahlR+r9neC1U6tWvtQ0zQgMLAFpiuHxCorhZq1l1+wBuE1ox+QL+1aT4mHcde KKpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a/P1YpUhSHF2aShxzSXp+nBBTK1awLJozmjOXShN2NU=; b=AfawT/PTwt+h8IpHLjFtd6nyjixPF2Y5PjCCDNpWlnmLjGoseP6sY1iNfP/6OJWn/t xtopKgyHVEHUTCZaThmFEJfV2mRGdeg5oIvOPTTvWX+BH/3RgGl9i/Tomuwat0eUDJMK R4XjALlLQHg7utEEJWK+8mPbegqEsOjgg85mcqR1OVFgGjcyB8WDTCN7TZQ8M1ZuxQe7 QsZ66i64js9pN8brDrtPoKZbaCJsYgI4LUkoH45KPIiQFC+zh8ZsAe0l5aWiWmN2dOg9 PN1vTYgZCgw23/1BvbnK3R+WV0uV/MbQXdcvcjMB3fYO0bTD6ImiZQhRX0h0d8+UrnRl ASPg== X-Gm-Message-State: ALQs6tB+oTddpYGwZrAyhNl4GI7OVFWkAj/UIzoqkB3Tp7wQsJheMmhn iyS1OTCqzRTVUrepyeN2Y8/j7fkZDKuOmpGV9CSC7A== X-Google-Smtp-Source: AIpwx4+KABqT2n6rOtyqBS4RQdJWUnCmnUJLooJetdfyE5mXWlkMFOwpRLtWB1EyIY0212ZvPSxLxLkSQnaDK9j5M/E= X-Received: by 10.159.35.105 with SMTP id 96mr6237702uae.100.1524182587512; Thu, 19 Apr 2018 17:03:07 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> In-Reply-To: From: Justin Uberti Date: Fri, 20 Apr 2018 00:02:54 +0000 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="001a11352a06b408a5056a3c690c" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 00:03:12 -0000 --001a11352a06b408a5056a3c690c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl wrote: > On 20.04.2018 01:29, Justin Uberti wrote: > > On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier > wrote: > > > >> While I understand the arguments against adding more mode I still thin= k > >> the paragraph describing Mode 4 is missing details and causes confusio= n > >> among implementers: > >> > >> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HTTP= proxy or a TURN > >> server. > >> > >> This can easily be improved by replacing the word =E2=80=9Cproxy=E2=80= =9D with =E2=80=9CHTTP > >> proxy=E2=80=9D everywhere in the Mode 4 paragraph. > >> > > > > The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or RETUR= N > > proxy (SOCKS is specifically noted in the para). > > > >> > >> - It is unclear how an implementation should behave in the absence of > such > >> a proxy. > >> > >> I would suggest to add a sentence the implementation should not hand o= ut > >> any candidates in the absence of a HTTP proxy. > >> > > > > This is a fair point. However, my take is that the behavior should be t= he > > same as Mode 3 in this case, as the web server already sees the client > IP. > > I could add a sentence to make this super clear. > > The web server, yes. But not the other peer. I don't think we can assume > trust towards the web server equals trust towards the other peer. I > would agree with Nils that it shouldn't hand out any candidates in this > case. > This is not unique to Mode 4. This scenario is discussed in detail in https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4; I don't think it needs special mention in this doc. --001a11352a06b408a5056a3c690c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Apr 19, 2018 at 4:41 PM Lennart Grahl <lennart.grahl@gmail.com> wrote:
On 20.04.2018 01:29, Justin Uberti wrote= :
> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:=
>
>> While I understand the arguments against adding more mode I still = think
>> the paragraph describing Mode 4 is missing details and causes conf= usion
>> among implementers:
>>
>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a = HTTP proxy or a TURN
>> server.
>>
>> This can easily be improved by replacing the word =E2=80=9Cproxy= =E2=80=9D with =E2=80=9CHTTP
>> proxy=E2=80=9D everywhere in the Mode 4 paragraph.
>>
>
> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or = RETURN
> proxy (SOCKS is specifically noted in the para).
>
>>
>> - It is unclear how an implementation should behave in the absence= of such
>> a proxy.
>>
>> I would suggest to add a sentence the implementation should not ha= nd out
>> any candidates in the absence of a HTTP proxy.
>>
>
> This is a fair point. However, my take is that the behavior should be = the
> same as Mode 3 in this case, as the web server already sees the client= IP.
> I could add a sentence to make this super clear.

The web server, yes. But not the other peer. I don't think we can assum= e
trust towards the web server equals trust towards the other peer. I
would agree with Nils that it shouldn't hand out any candidates in this=
case.

This is not unique to Mode 4.

This scenario is discussed in detail in=C2=A0https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section= -5.4; I don't think it needs special mention in this doc.
--001a11352a06b408a5056a3c690c-- From nobody Thu Apr 19 18:10:44 2018 Return-Path: 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 4E93712E8A6 for ; Thu, 19 Apr 2018 18:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3XzMgf5BvEAb for ; Thu, 19 Apr 2018 18:10:40 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B4A1270A7 for ; Thu, 19 Apr 2018 18:10:40 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id z73-v6so18612700wrb.0 for ; Thu, 19 Apr 2018 18:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+Xi+EAszD1o3Z2dzwszvoe+JxMqXgGOZ+HwXhAhhfR0=; b=D1VDx+SeqA15Nc9RCh8SJJXZoPNqL6c8uN+C/SrMxFpTYUCkvJMsCYpMCesp69pOqj aQBoKWSdrO3u53BkE/COwa1UGyHQ9MhmguHPeMgma1zeDw7M6rW2Pumc5dNeWPvxQOcJ RzbmYXBiSeMJYgWgfA07tsF6IdndCAAO9Xj2h5Bjyh8iw3rqNZl3LKjZ6joHtppww41Y jKBlKG9MRReHDTrKCE/9EtKfQfTRF7ufgM4IjKDe4WLTwOXswdQIfE9UKkFvg9/bHSoA BsfJ6SluHdTCR72ZfvJo1+4IvDtzmFG9ea0pDbjRoqBWCXQBcxMvg9RUYUDJFJPeHOFL 7vpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+Xi+EAszD1o3Z2dzwszvoe+JxMqXgGOZ+HwXhAhhfR0=; b=NoGJkakUgM11UCOZDS8ZMoZK5ZrBjNaIuXRXSxrgq90iDmDqf7W7sZMsATcMXui6b5 fy441yB2xsJ4dhp3deGub0uL6eUpYRrmOqlUjAmLTnTYV9JKJRPj52lR+J5ia64b5svy EXvfl5MvrL5tNk3MS5KLZ1CuFi4zFJRf2HkZbfqLjp5BgRW6/J6UerWkJrc1FJA2n0nT upmcK9jcZBYkzTDHnQDZ4KeCGNt/5gWSFoqPLH1nRRPt0ExHA0VJ90WZtYD8pW1uygxC 7QWlvHe2uRGIjBmFFQwxXPa4u6TajTUmcmbV8BMYzPZIq/P0cDOMYVG3lFKSJVb/+Ckz 8bPw== X-Gm-Message-State: ALQs6tAN1/4WCp0rXC7WfkFcsm49f6fnvOfxL9mr/HUDpjTsOxuL3zj6 PRx/fwivhPJBLujR2lvMkM1vOw== X-Google-Smtp-Source: AIpwx49UQgkcWSZBABpL5BpnQDBHTFCuPaGdPtJ0EXFrc9kUufEoFG9JlQNoAKDeL+godUAW+OwOkA== X-Received: by 2002:adf:a219:: with SMTP id p25-v6mr6150312wra.154.1524186638086; Thu, 19 Apr 2018 18:10:38 -0700 (PDT) Received: from ?IPv6:2003:cd:6f24:eb00:b4bb:a980:85e1:c6f9? (p200300CD6F24EB00B4BBA98085E1C6F9.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:b4bb:a980:85e1:c6f9]) by smtp.gmail.com with ESMTPSA id 44-v6sm4004950wrl.83.2018.04.19.18.10.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 18:10:37 -0700 (PDT) To: Justin Uberti Cc: RTCWeb IETF References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: Date: Fri, 20 Apr 2018 03:10:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 01:10:42 -0000 On 20.04.2018 02:02, Justin Uberti wrote: > On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl > wrote: > >> On 20.04.2018 01:29, Justin Uberti wrote: >>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier >> wrote: >>> >>>> While I understand the arguments against adding more mode I still think >>>> the paragraph describing Mode 4 is missing details and causes confusion >>>> among implementers: >>>> >>>> - It is not clear if the word “proxy” refers to a HTTP proxy or a TURN >>>> server. >>>> >>>> This can easily be improved by replacing the word “proxy” with “HTTP >>>> proxy” everywhere in the Mode 4 paragraph. >>>> >>> >>> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or RETURN >>> proxy (SOCKS is specifically noted in the para). >>> >>>> >>>> - It is unclear how an implementation should behave in the absence of >> such >>>> a proxy. >>>> >>>> I would suggest to add a sentence the implementation should not hand out >>>> any candidates in the absence of a HTTP proxy. >>>> >>> >>> This is a fair point. However, my take is that the behavior should be the >>> same as Mode 3 in this case, as the web server already sees the client >> IP. >>> I could add a sentence to make this super clear. >> >> The web server, yes. But not the other peer. I don't think we can assume >> trust towards the web server equals trust towards the other peer. I >> would agree with Nils that it shouldn't hand out any candidates in this >> case. >> > > This is not unique to Mode 4. > > This scenario is discussed in detail in > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4; > I don't think it needs special mention in this doc. Still, I see no possibility for the user to voice it's opinion in this matter. However, that may simply be an issue for the browser vendors to resolve (by providing additional browser settings - I think at least Firefox does that already). Then it probably should be clarified because if I'm not mistaken Chrome gets it wrong, too (no proxy = no candidates). Unless that fourth mode does not actually map to mode 4 (see https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q=rtcIPHandling&sq=package:chromium&dr=CSs&l=15). Cheers Lennart From nobody Fri Apr 20 05:50:11 2018 Return-Path: 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 3069412D77A for ; Fri, 20 Apr 2018 05:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 HgmJGLlBPGbC for ; Fri, 20 Apr 2018 05:50:07 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDCF812751F for ; Fri, 20 Apr 2018 05:50:06 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id f20-v6so9350902qtp.7 for ; Fri, 20 Apr 2018 05:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HFghUBsMXdnUffMP5ZRpHTuzecUBXRLNV909EvGMK4U=; b=WLbfjwsMNiraEFP2M3qxgNinmPFe3gCmT4JiuXsbMrSWmdcy+SThGOIRYj7/buJgWI aoV2rCCGzXz3PooKeYQKOsY76AFa7yuaZTwHrYa4YnkotZfcidni0iavDNHN6MCU4rJ8 1Wgz8b9/GdliYcK2EoH4g0TfaeQFHIy2rQYlM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HFghUBsMXdnUffMP5ZRpHTuzecUBXRLNV909EvGMK4U=; b=sHlDmICt8rPyo0jLVl+SBHH+Jbx/WLPz9ugvflXizybq9SKfgHDdOw8iHERq9vGR6k 5nWmAehjDeWYKQ+U0kOrKtlkQMxnbLYLsrJfO9NqykDiEPOUT0uYMCX0ZQKpivvlfdIA /GtrfpDjXAewubbl1xpNKsyxq0SQH58QY2EcIXkT4j7KZV/7HWU4ezSsm3TXaqCWy8QZ cKwTsFzRVDzJYH9/FNdAxSCzpBJXNI47KWByPX1Z+tTBc5iHeInHXAWK+eG5xQxMNBI3 DKhf8CcZHC+1InKtvbRCaKt5KeBxqlZx2JgdaXgWAa/iStA41ptFhkLeZQRFEgdtfIOh wMyg== X-Gm-Message-State: ALQs6tA5qoHmIEX4/ljvQNUTysXFAPJB7bIc2wRRHjT06E9xwEs6vr+G lw1FHH8gLKauv3gvv4X4Gl45Fg== X-Google-Smtp-Source: AIpwx4/v/td/PUbdT87FiERVYzkINfIZzcojIqo26PvNVGsv9GcdpSqQZ+tq0mU+UhdK4s/jOd4yRA== X-Received: by 2002:ac8:2dbb:: with SMTP id p56-v6mr11174728qta.104.1524228606012; Fri, 20 Apr 2018 05:50:06 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id t13-v6sm5157524qte.77.2018.04.20.05.50.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Apr 2018 05:50:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: Date: Fri, 20 Apr 2018 08:50:03 -0400 Cc: Justin Uberti , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <0B04D27C-316A-41D2-91B9-01CD2A784D68@sn3rd.com> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> To: Lennart Grahl X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 12:50:09 -0000 I=E2=80=99m going to go ahead and push this draft towards Adam (our AD) = and we=E2=80=99ll treat this as an IETF LC comment to get fixed up = before the IESG telechat (i.e., Justin just throw a PR in for whatever = change, but there=E2=80=99s no need to spin a new version). spt > On Apr 19, 2018, at 21:10, Lennart Grahl = wrote: >=20 > On 20.04.2018 02:02, Justin Uberti wrote: >> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl = >> wrote: >>=20 >>> On 20.04.2018 01:29, Justin Uberti wrote: >>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier = >>> wrote: >>>>=20 >>>>> While I understand the arguments against adding more mode I still = think >>>>> the paragraph describing Mode 4 is missing details and causes = confusion >>>>> among implementers: >>>>>=20 >>>>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a = HTTP proxy or a TURN >>>>> server. >>>>>=20 >>>>> This can easily be improved by replacing the word =E2=80=9Cproxy=E2=80= =9D with =E2=80=9CHTTP >>>>> proxy=E2=80=9D everywhere in the Mode 4 paragraph. >>>>>=20 >>>>=20 >>>> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or = RETURN >>>> proxy (SOCKS is specifically noted in the para). >>>>=20 >>>>>=20 >>>>> - It is unclear how an implementation should behave in the absence = of >>> such >>>>> a proxy. >>>>>=20 >>>>> I would suggest to add a sentence the implementation should not = hand out >>>>> any candidates in the absence of a HTTP proxy. >>>>>=20 >>>>=20 >>>> This is a fair point. However, my take is that the behavior should = be the >>>> same as Mode 3 in this case, as the web server already sees the = client >>> IP. >>>> I could add a sentence to make this super clear. >>>=20 >>> The web server, yes. But not the other peer. I don't think we can = assume >>> trust towards the web server equals trust towards the other peer. I >>> would agree with Nils that it shouldn't hand out any candidates in = this >>> case. >>>=20 >>=20 >> This is not unique to Mode 4. >>=20 >> This scenario is discussed in detail in >> = https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4= ; >> I don't think it needs special mention in this doc. >=20 > Still, I see no possibility for the user to voice it's opinion in this > matter. However, that may simply be an issue for the browser vendors = to > resolve (by providing additional browser settings - I think at least > Firefox does that already). >=20 > Then it probably should be clarified because if I'm not mistaken = Chrome > gets it wrong, too (no proxy =3D no candidates). Unless that fourth = mode > does not actually map to mode 4 (see > = https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_handl= ing_policy.cc?q=3DrtcIPHandling&sq=3Dpackage:chromium&dr=3DCSs&l=3D15). >=20 > Cheers > Lennart >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Apr 20 05:52:05 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9A712D77E; Fri, 20 Apr 2018 05:52:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, Sean Turner , rtcweb@ietf.org, sean@sn3rd.com, rtcweb-chairs@ietf.org Message-ID: <152422872397.3484.187592412925629936.idtracker@ietfa.amsl.com> Date: Fri, 20 Apr 2018 05:52:03 -0700 Archived-At: Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-ip-handling-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 12:52:04 -0000 Sean Turner has requested publication of draft-ietf-rtcweb-ip-handling-07 as Proposed Standard on behalf of the RTCWEB working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ From nobody Fri Apr 20 07:24:35 2018 Return-Path: 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 89BD71270B4 for ; Fri, 20 Apr 2018 07:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Mm5bkbWJxs0Y for ; Fri, 20 Apr 2018 07:24:31 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56A7129C53 for ; Fri, 20 Apr 2018 07:24:30 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id c9so5813944uaf.7 for ; Fri, 20 Apr 2018 07:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cuClhca56SXYMm17OrHqEn5PZPvJ6ckzxgxqD1up6Gc=; b=cd+Mo4JtN5T1O/1u1rGxsw/v1xZu0DJDrBK9KRxBOvShPOEj9pKlSKfHonP4sPUQD3 3JoSdh4h3+3RoCOTKnLaGOGb273Qbq2/X/83bvM6+UK5m8VKpOlErhJ2KZqovI6x9MDr mXEQSN9uYyPJkV5tF8mSEJkuCq3yKHYswZFK4KlDV97ejFoTyytiAEEAcPnhb8aq/lrr nkWCbjL1z2O9e8m7M0ruDfM+PDnGvltonevWpLXYkiQl5C/Jm9k7bRlEkXupreVLbyqB wP0Swtls1dNgFjAu8nrh73Mt5fhZ+KUSbUGvf3lU+EJbSswOEttGPEmKpfani0i55C5l J14A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cuClhca56SXYMm17OrHqEn5PZPvJ6ckzxgxqD1up6Gc=; b=NQ2M7YbH4W3AZ40tflu6YEp/y7kDqD8Pu+QEGj8+k7kHKFAdJHun6ufAk5KOBNr/aY wBdP7pBLMQU0HAiYNCz82Slu0fZKH/3N7u4Bt/A5XrpRFcj2qfyhS2lwZtJuiIXF4FSS Lq4kQzUlL9fiV9Z2sm80kdxvx3MYH71ee6JvvLR7AZv61W6cyJZRFOmMVuq5nPPRD5ue eAeP+KKnd1bJ/yQf1FY7D4rTUeD3bID/ntd15djPV/kA4oI/ByPAiwqveQiDriDAbfxk Dc4DanatnVEjQ18BxAc6P4th6aa6ReTGcEkVzrrb6lrjpdK4TuuFjD8fgi7+tqScdtI0 IGBA== X-Gm-Message-State: ALQs6tDwfLeqTtOm9dXhrMIA7qsgKQqWwDInuP4cMOIDv2zD3P+bifmq yE7o4rzJcpDnpC+NhoghdY/O0GX3uOzorEfBA0AtSaP9B3U= X-Google-Smtp-Source: AIpwx4+QGEV+VH8+uWT5ZYwExPtfu+DhXJOXX4rRKFePD5w7mnMQkjXY41WGhoWVqizmNE59Cu+ZXZma7uXkVZLRqk0= X-Received: by 10.176.112.23 with SMTP id k23mr356712ual.60.1524234269430; Fri, 20 Apr 2018 07:24:29 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> In-Reply-To: From: Justin Uberti Date: Fri, 20 Apr 2018 14:24:16 +0000 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="089e082e91882fe0f7056a487285" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 14:24:33 -0000 --089e082e91882fe0f7056a487285 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 19, 2018 at 6:10 PM Lennart Grahl wrote: > On 20.04.2018 02:02, Justin Uberti wrote: > > On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl > > wrote: > > > >> On 20.04.2018 01:29, Justin Uberti wrote: > >>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier > >> wrote: > >>> > >>>> While I understand the arguments against adding more mode I still > think > >>>> the paragraph describing Mode 4 is missing details and causes > confusion > >>>> among implementers: > >>>> > >>>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a HT= TP proxy or a TURN > >>>> server. > >>>> > >>>> This can easily be improved by replacing the word =E2=80=9Cproxy=E2= =80=9D with =E2=80=9CHTTP > >>>> proxy=E2=80=9D everywhere in the Mode 4 paragraph. > >>>> > >>> > >>> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or > RETURN > >>> proxy (SOCKS is specifically noted in the para). > >>> > >>>> > >>>> - It is unclear how an implementation should behave in the absence o= f > >> such > >>>> a proxy. > >>>> > >>>> I would suggest to add a sentence the implementation should not hand > out > >>>> any candidates in the absence of a HTTP proxy. > >>>> > >>> > >>> This is a fair point. However, my take is that the behavior should be > the > >>> same as Mode 3 in this case, as the web server already sees the clien= t > >> IP. > >>> I could add a sentence to make this super clear. > >> > >> The web server, yes. But not the other peer. I don't think we can assu= me > >> trust towards the web server equals trust towards the other peer. I > >> would agree with Nils that it shouldn't hand out any candidates in thi= s > >> case. > >> > > > > This is not unique to Mode 4. > > > > This scenario is discussed in detail in > > > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.= 4 > ; > > I don't think it needs special mention in this doc. > > Still, I see no possibility for the user to voice it's opinion in this > matter. However, that may simply be an issue for the browser vendors to > resolve (by providing additional browser settings - I think at least > Firefox does that already). > > Then it probably should be clarified because if I'm not mistaken Chrome > gets it wrong, too (no proxy =3D no candidates). Unless that fourth mode > does not actually map to mode 4 (see > > https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_hand= ling_policy.cc?q=3DrtcIPHandling&sq=3Dpackage:chromium&dr=3DCSs&l=3D15 > ). > > In Chrome Mode 4 is currently over-conservative, it forces the use of TCP, and those TCP connections are sent through a proxy if one exists. This is because "is a proxy present?" is a per-destination question (at least when PAC files are used ), and as such was difficult to determine a priori. FWIW, you can try it out at https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbka= kmehahjeeohfdhnlpdklia?hl=3Den . --089e082e91882fe0f7056a487285 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Apr 19, 2018 at 6:10 PM Lennart Grahl <lennart.grahl@gmail.com> wrote:
On 20.04.2018 02:02, Justin Uberti wrote= :
> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <lennart.grahl@gmail.com> > wrote:
>
>> On 20.04.2018 01:29, Justin Uberti wrote:
>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com>= ;
>> wrote:
>>>
>>>> While I understand the arguments against adding more mode = I still think
>>>> the paragraph describing Mode 4 is missing details and cau= ses confusion
>>>> among implementers:
>>>>
>>>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refe= rs to a HTTP proxy or a TURN
>>>> server.
>>>>
>>>> This can easily be improved by replacing the word =E2=80= =9Cproxy=E2=80=9D with =E2=80=9CHTTP
>>>> proxy=E2=80=9D everywhere in the Mode 4 paragraph.
>>>>
>>>
>>> The proxy doesn't need to be a HTTP proxy; it could be a S= OCKS or RETURN
>>> proxy (SOCKS is specifically noted in the para).
>>>
>>>>
>>>> - It is unclear how an implementation should behave in the= absence of
>> such
>>>> a proxy.
>>>>
>>>> I would suggest to add a sentence the implementation shoul= d not hand out
>>>> any candidates in the absence of a HTTP proxy.
>>>>
>>>
>>> This is a fair point. However, my take is that the behavior sh= ould be the
>>> same as Mode 3 in this case, as the web server already sees th= e client
>> IP.
>>> I could add a sentence to make this super clear.
>>
>> The web server, yes. But not the other peer. I don't think we = can assume
>> trust towards the web server equals trust towards the other peer. = I
>> would agree with Nils that it shouldn't hand out any candidate= s in this
>> case.
>>
>
> This is not unique to Mode 4.
>
> This scenario is discussed in detail in
> https://tools.ietf.or= g/html/draft-ietf-rtcweb-security-arch-14#section-5.4;
> I don't think it needs special mention in this doc.

Still, I see no possibility for the user to voice it's opinion in this<= br> matter. However, that may simply be an issue for the browser vendors to
resolve (by providing additional browser settings - I think at least
Firefox does that already).

Then it probably should be clarified because if I'm not mistaken Chrome=
gets it wrong, too (no proxy =3D no candidates). Unless that fourth mode does not actually map to mode 4 (see
https://cs.chromium= .org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q=3Drt= cIPHandling&sq=3Dpackage:chromium&dr=3DCSs&l=3D15).

=

In Chrome Mode 4 is currently over-conserv= ative, it forces the use of TCP, and those TCP connections are sent through= a proxy if one exists. This is because "is a proxy present?" is = a per-destination question (at least when PAC files are used), and as suc= h was difficult to determine a priori.

--089e082e91882fe0f7056a487285-- From nobody Fri Apr 20 07:49:03 2018 Return-Path: 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 8951912D77E for ; Fri, 20 Apr 2018 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 AfKYjxjMDFi6 for ; Fri, 20 Apr 2018 07:48:58 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA101241FC for ; Fri, 20 Apr 2018 07:48:58 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id d3so5866447uae.4 for ; Fri, 20 Apr 2018 07:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YW1EYoOuMZHSn5PVqDO7XEzjkZKt9f2sAwhCR0qMp88=; b=V8AQ1bpPNYEMuuSjSXfju5Nl7r34Z4aROWfZOc7sThG7AOdzah+rWHis+YaBNwy0dH fqrLd23RWmS8PnemDB9sqVg4xdU0mbk7slsCIhRzPElB6FdW1w8VCJW+GR0ueFnubtCI RYywIbavLv2Mitd09up9mOj/RvFgMvwCS86+9jZFjI6J/woKlW6QHddtkJVdIchl3suM IS7wz44E/zBc5Lee8z1E+wU/Sw/S9xNyFoeNqxQQMIlCvLw5xNIYM1ETKNyD6pD9y+69 K0LYNhafi+EGrfwbM7HrEtF6oyPXuXiC5v38pEgDOKFGRf35P1JN+M1Fh/NO2XrbC05c jleg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YW1EYoOuMZHSn5PVqDO7XEzjkZKt9f2sAwhCR0qMp88=; b=Y87QJ96AvqI4Rb9rMWDGu8MIl1QGzelBQyqk1Eyivg3vtAASklT6L9J87tEMnzeUCR LnejDNtxmwDlB4VBiw9I2rze4RKmfZ3gu5tKuVvwFYGzWpDB8mrgkgc52T7TM9mD3JKI ENxnjHiZQ3Y8vj3rZvvumPb+usFV9RFF/nYmuMw72UgYkdAtRYovJaowZe5q2MUiOrDp uGCmynqy2xxNsxyiXGqkdTMYbYsZqMyYwiqNsKyFX2poTvM6RaXTN/Fx2oltB8wOS5p8 8ZC7YnAowNTQQd41AGNKChblxDOeaKhPs/qgu/dOaUv6iKHcKILrvEegx1Mh2SDpHAas Mw/Q== X-Gm-Message-State: ALQs6tCukNqjwXn1kSmNIvePTlnsULynK7GwI/DEqUfK+8+nIQAjaT45 hNtiBEaHljrpRcGszMJfIGrG0FEcVfS9snm4mqzSxA== X-Google-Smtp-Source: AIpwx48Ft6GQcGL39VKj7O3MozByahSX44f4hPFwa+0zVEvoLic4buESUYcd0uXzxyJQvjfW4VEQICG1lyPjAvBe/cE= X-Received: by 10.159.41.99 with SMTP id t90mr7879955uat.127.1524235737188; Fri, 20 Apr 2018 07:48:57 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> <0B04D27C-316A-41D2-91B9-01CD2A784D68@sn3rd.com> In-Reply-To: <0B04D27C-316A-41D2-91B9-01CD2A784D68@sn3rd.com> From: Justin Uberti Date: Fri, 20 Apr 2018 14:48:43 +0000 Message-ID: To: Sean Turner Cc: Lennart Grahl , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a114dfb38ac1b31056a48c910" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 14:49:01 -0000 --001a114dfb38ac1b31056a48c910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Small PR for improved text: https://github.com/juberti/draughts/pull/100/files On Fri, Apr 20, 2018 at 5:50 AM Sean Turner wrote: > I=E2=80=99m going to go ahead and push this draft towards Adam (our AD) a= nd we=E2=80=99ll > treat this as an IETF LC comment to get fixed up before the IESG telechat > (i.e., Justin just throw a PR in for whatever change, but there=E2=80=99s= no need > to spin a new version). > > spt > > > On Apr 19, 2018, at 21:10, Lennart Grahl > wrote: > > > > On 20.04.2018 02:02, Justin Uberti wrote: > >> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl > >> wrote: > >> > >>> On 20.04.2018 01:29, Justin Uberti wrote: > >>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier > >>> wrote: > >>>> > >>>>> While I understand the arguments against adding more mode I still > think > >>>>> the paragraph describing Mode 4 is missing details and causes > confusion > >>>>> among implementers: > >>>>> > >>>>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a H= TTP proxy or a > TURN > >>>>> server. > >>>>> > >>>>> This can easily be improved by replacing the word =E2=80=9Cproxy=E2= =80=9D with =E2=80=9CHTTP > >>>>> proxy=E2=80=9D everywhere in the Mode 4 paragraph. > >>>>> > >>>> > >>>> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or > RETURN > >>>> proxy (SOCKS is specifically noted in the para). > >>>> > >>>>> > >>>>> - It is unclear how an implementation should behave in the absence = of > >>> such > >>>>> a proxy. > >>>>> > >>>>> I would suggest to add a sentence the implementation should not han= d > out > >>>>> any candidates in the absence of a HTTP proxy. > >>>>> > >>>> > >>>> This is a fair point. However, my take is that the behavior should b= e > the > >>>> same as Mode 3 in this case, as the web server already sees the clie= nt > >>> IP. > >>>> I could add a sentence to make this super clear. > >>> > >>> The web server, yes. But not the other peer. I don't think we can > assume > >>> trust towards the web server equals trust towards the other peer. I > >>> would agree with Nils that it shouldn't hand out any candidates in th= is > >>> case. > >>> > >> > >> This is not unique to Mode 4. > >> > >> This scenario is discussed in detail in > >> > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.= 4 > ; > >> I don't think it needs special mention in this doc. > > > > Still, I see no possibility for the user to voice it's opinion in this > > matter. However, that may simply be an issue for the browser vendors to > > resolve (by providing additional browser settings - I think at least > > Firefox does that already). > > > > Then it probably should be clarified because if I'm not mistaken Chrome > > gets it wrong, too (no proxy =3D no candidates). Unless that fourth mod= e > > does not actually map to mode 4 (see > > > https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_hand= ling_policy.cc?q=3DrtcIPHandling&sq=3Dpackage:chromium&dr=3DCSs&l=3D15 > ). > > > > Cheers > > Lennart > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a114dfb38ac1b31056a48c910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 20, 2018 at 5:50 AM Sean Turner <sean@sn3rd.com> wrote:
I= =E2=80=99m going to go ahead and push this draft towards Adam (our AD) and = we=E2=80=99ll treat this as an IETF LC comment to get fixed up before the I= ESG telechat (i.e., Justin just throw a PR in for whatever change, but ther= e=E2=80=99s no need to spin a new version).

spt

> On Apr 19, 2018, at 21:10, Lennart Grahl <lennart.grahl@gmail.com> wrote:<= br> >
> On 20.04.2018 02:02, Justin Uberti wrote:
>> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <lennart.grahl@gmail.com>= ;
>> wrote:
>>
>>> On 20.04.2018 01:29, Justin Uberti wrote:
>>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com>
>>> wrote:
>>>>
>>>>> While I understand the arguments against adding more m= ode I still think
>>>>> the paragraph describing Mode 4 is missing details and= causes confusion
>>>>> among implementers:
>>>>>
>>>>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D = refers to a HTTP proxy or a TURN
>>>>> server.
>>>>>
>>>>> This can easily be improved by replacing the word =E2= =80=9Cproxy=E2=80=9D with =E2=80=9CHTTP
>>>>> proxy=E2=80=9D everywhere in the Mode 4 paragraph.
>>>>>
>>>>
>>>> The proxy doesn't need to be a HTTP proxy; it could be= a SOCKS or RETURN
>>>> proxy (SOCKS is specifically noted in the para).
>>>>
>>>>>
>>>>> - It is unclear how an implementation should behave in= the absence of
>>> such
>>>>> a proxy.
>>>>>
>>>>> I would suggest to add a sentence the implementation s= hould not hand out
>>>>> any candidates in the absence of a HTTP proxy.
>>>>>
>>>>
>>>> This is a fair point. However, my take is that the behavio= r should be the
>>>> same as Mode 3 in this case, as the web server already see= s the client
>>> IP.
>>>> I could add a sentence to make this super clear.
>>>
>>> The web server, yes. But not the other peer. I don't think= we can assume
>>> trust towards the web server equals trust towards the other pe= er. I
>>> would agree with Nils that it shouldn't hand out any candi= dates in this
>>> case.
>>>
>>
>> This is not unique to Mode 4.
>>
>> This scenario is discussed in detail in
>> https://tools.iet= f.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4;
>> I don't think it needs special mention in this doc.
>
> Still, I see no possibility for the user to voice it's opinion in = this
> matter. However, that may simply be an issue for the browser vendors t= o
> resolve (by providing additional browser settings - I think at least > Firefox does that already).
>
> Then it probably should be clarified because if I'm not mistaken C= hrome
> gets it wrong, too (no proxy =3D no candidates). Unless that fourth mo= de
> does not actually map to mode 4 (see
> https://cs.chro= mium.org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q= =3DrtcIPHandling&sq=3Dpackage:chromium&dr=3DCSs&l=3D15). >
> Cheers
> Lennart
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
--001a114dfb38ac1b31056a48c910-- From nobody Fri Apr 20 10:18:44 2018 Return-Path: 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 A7689127136 for ; Fri, 20 Apr 2018 10:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 jcgITy7IKnnN for ; Fri, 20 Apr 2018 10:18:40 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD5D126DFF for ; Fri, 20 Apr 2018 10:18:40 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id z12-v6so5619328plo.1 for ; Fri, 20 Apr 2018 10:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AM4MAGSuxbFNoLcNou7wi9HXahaV8O9fBVCx9c9ktg8=; b=WkCAJ5D9XYI3xJAiiI8to3HniBqQC34nsz0yVGFbzJmkTG8Em5tyJ5CimIy/sB+vQX Iks/Hao4gJuxKxB6ryyiiFNS832oV5HN6dOWNWGkP8qP26b+rqSodYVfDhbJvzWbEXdz F+rZPv0UQyyHrrtnM1DCrIiq+WWNz725wp8FQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AM4MAGSuxbFNoLcNou7wi9HXahaV8O9fBVCx9c9ktg8=; b=JOeRC8LqpFL5Z6Ri52vLgrKNHqsokSQHWvSiuhyOeAIcCw+30JCUBywfSpWR3tknye OrWPn+KbLNB3d5blDVSOZONzCOI91UpaWX67V8VY9TiW1KtpwLuk3n79nXH6onudw0as FPgTcQfzxklP7+8beO5+17bk/VaIpKI/eHopM6w+GLyAb1tLF4nFilf/IGQDSLgvIMqH zI3BjgH6ObF+m2EjbdwlGa0B+27MzaV+sqcTILJHqncHM94yEO7EmzeVbRXaUAU+yjiD jDM3l5jaF6r33ZBdTGRAognxsMEep9wN1up/W4usmbi3yRxFur1TGbTkAYkR4t2uuN9+ tGNw== X-Gm-Message-State: ALQs6tAXC7Y1uWfOwi5GxFcvklYxlOe77MsB3r6YArAESJFVTQEg3Kd/ rYeUXZODoEK/UJWAlcfdKmP6czfJgPIrtg== X-Google-Smtp-Source: AIpwx4+3X9VOo/KmbmULvYuhO31pQQob4WhgLlLQrfXVFFbYEJwWlF1JQGLFSPc5xvL6bHutd5Ov9A== X-Received: by 2002:a17:902:8b89:: with SMTP id ay9-v6mr11107632plb.100.1524244719908; Fri, 20 Apr 2018 10:18:39 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:6188:f3e:7c62:d5f0? ([2620:101:80fc:224:6188:f3e:7c62:d5f0]) by smtp.gmail.com with ESMTPSA id y3sm9600203pgc.81.2018.04.20.10.18.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Apr 2018 10:18:37 -0700 (PDT) From: Nils Ohlmeier Message-Id: <8F091C3B-D150-4196-85DB-B5C42AD6E4F0@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_27AC6148-F0F7-4118-9CDD-5E06C34FB1F6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 20 Apr 2018 10:18:35 -0700 In-Reply-To: Cc: Sean Turner , RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> <0B04D27C-316A-41D2-91B9-01CD2A784D68@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 17:18:44 -0000 --Apple-Mail=_27AC6148-F0F7-4118-9CDD-5E06C34FB1F6 Content-Type: multipart/alternative; boundary="Apple-Mail=_35782B66-B96E-47C7-A3ED-B44AC0F51376" --Apple-Mail=_35782B66-B96E-47C7-A3ED-B44AC0F51376 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 20, 2018, at 07:48, Justin Uberti = wrote: >=20 > Small PR for improved text: = https://github.com/juberti/draughts/pull/100/files = I think this helps. I guess that the implementation is suppose to fall back to mode 3 (vs = not work at all) derives from the =E2=80=9CThis is the same as Mode = 3,=E2=80=A6=E2=80=9D part? The only option which comes to my mind to make this more explicit would = be to add another sentence like =E2=80=9CIf the applications HTTP = traffic is not proxied it should fall back to Mode 3=E2=80=9D. Nils > On Fri, Apr 20, 2018 at 5:50 AM Sean Turner > wrote: > I=E2=80=99m going to go ahead and push this draft towards Adam (our = AD) and we=E2=80=99ll treat this as an IETF LC comment to get fixed up = before the IESG telechat (i.e., Justin just throw a PR in for whatever = change, but there=E2=80=99s no need to spin a new version). >=20 > spt >=20 > > On Apr 19, 2018, at 21:10, Lennart Grahl > wrote: > > > > On 20.04.2018 02:02, Justin Uberti wrote: > >> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl = > > >> wrote: > >> > >>> On 20.04.2018 01:29, Justin Uberti wrote: > >>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier = > > >>> wrote: > >>>> > >>>>> While I understand the arguments against adding more mode I = still think > >>>>> the paragraph describing Mode 4 is missing details and causes = confusion > >>>>> among implementers: > >>>>> > >>>>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to = a HTTP proxy or a TURN > >>>>> server. > >>>>> > >>>>> This can easily be improved by replacing the word =E2=80=9Cproxy=E2= =80=9D with =E2=80=9CHTTP > >>>>> proxy=E2=80=9D everywhere in the Mode 4 paragraph. > >>>>> > >>>> > >>>> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or = RETURN > >>>> proxy (SOCKS is specifically noted in the para). > >>>> > >>>>> > >>>>> - It is unclear how an implementation should behave in the = absence of > >>> such > >>>>> a proxy. > >>>>> > >>>>> I would suggest to add a sentence the implementation should not = hand out > >>>>> any candidates in the absence of a HTTP proxy. > >>>>> > >>>> > >>>> This is a fair point. However, my take is that the behavior = should be the > >>>> same as Mode 3 in this case, as the web server already sees the = client > >>> IP. > >>>> I could add a sentence to make this super clear. > >>> > >>> The web server, yes. But not the other peer. I don't think we can = assume > >>> trust towards the web server equals trust towards the other peer. = I > >>> would agree with Nils that it shouldn't hand out any candidates in = this > >>> case. > >>> > >> > >> This is not unique to Mode 4. > >> > >> This scenario is discussed in detail in > >> = https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4= = ; > >> I don't think it needs special mention in this doc. > > > > Still, I see no possibility for the user to voice it's opinion in = this > > matter. However, that may simply be an issue for the browser vendors = to > > resolve (by providing additional browser settings - I think at least > > Firefox does that already). > > > > Then it probably should be clarified because if I'm not mistaken = Chrome > > gets it wrong, too (no proxy =3D no candidates). Unless that fourth = mode > > does not actually map to mode 4 (see > > = https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_handl= ing_policy.cc?q=3DrtcIPHandling&sq=3Dpackage:chromium&dr=3DCSs&l=3D15 = ). > > > > Cheers > > Lennart > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb = >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_35782B66-B96E-47C7-A3ED-B44AC0F51376 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Apr 20, 2018, at 07:48, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

Small PR for improved text: https://github.com/juberti/draughts/pull/100/files

I think this = helps.

I guess that the = implementation is suppose to fall back to mode 3 (vs not work at all) = derives from the =E2=80=9CThis is the same as Mode 3,=E2=80=A6=E2=80=9D = part?
The only option which comes to my mind to make this more = explicit would be to add another sentence like =E2=80=9CIf the = applications HTTP traffic is not proxied it should fall back to Mode = 3=E2=80=9D.

  = Nils

On = Fri, Apr 20, 2018 at 5:50 AM Sean Turner <sean@sn3rd.com> = wrote:
I=E2=80=99m going to go ahead and push this = draft towards Adam (our AD) and we=E2=80=99ll treat this as an IETF LC = comment to get fixed up before the IESG telechat (i.e., Justin just = throw a PR in for whatever change, but there=E2=80=99s no need to spin a = new version).

spt

> On Apr 19, 2018, at 21:10, Lennart Grahl <lennart.grahl@gmail.com> wrote:
>
> On 20.04.2018 02:02, Justin Uberti wrote:
>> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <lennart.grahl@gmail.com>
>> wrote:
>>
>>> On 20.04.2018 01:29, Justin Uberti wrote:
>>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com>
>>> wrote:
>>>>
>>>>> While I understand the arguments against adding = more mode I still think
>>>>> the paragraph describing Mode 4 is missing details = and causes confusion
>>>>> among implementers:
>>>>>
>>>>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D= refers to a HTTP proxy or a TURN
>>>>> server.
>>>>>
>>>>> This can easily be improved by replacing the word = =E2=80=9Cproxy=E2=80=9D with =E2=80=9CHTTP
>>>>> proxy=E2=80=9D everywhere in the Mode 4 = paragraph.
>>>>>
>>>>
>>>> The proxy doesn't need to be a HTTP proxy; it could be = a SOCKS or RETURN
>>>> proxy (SOCKS is specifically noted in the para).
>>>>
>>>>>
>>>>> - It is unclear how an implementation should behave = in the absence of
>>> such
>>>>> a proxy.
>>>>>
>>>>> I would suggest to add a sentence the = implementation should not hand out
>>>>> any candidates in the absence of a HTTP proxy.
>>>>>
>>>>
>>>> This is a fair point. However, my take is that the = behavior should be the
>>>> same as Mode 3 in this case, as the web server already = sees the client
>>> IP.
>>>> I could add a sentence to make this super clear.
>>>
>>> The web server, yes. But not the other peer. I don't think = we can assume
>>> trust towards the web server equals trust towards the other = peer. I
>>> would agree with Nils that it shouldn't hand out any = candidates in this
>>> case.
>>>
>>
>> This is not unique to Mode 4.
>>
>> This scenario is discussed in detail in
>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#= section-5.4;
>> I don't think it needs special mention in this doc.
>
> Still, I see no possibility for the user to voice it's opinion in = this
> matter. However, that may simply be an issue for the browser = vendors to
> resolve (by providing additional browser settings - I think at = least
> Firefox does that already).
>
> Then it probably should be clarified because if I'm not mistaken = Chrome
> gets it wrong, too (no proxy =3D no candidates). Unless that fourth = mode
> does not actually map to mode 4 (see
> https://cs.chromium.org/chromium/src/content/public/common/webr= tc_ip_handling_policy.cc?q=3DrtcIPHandling&sq=3Dpackage:chromium&d= r=3DCSs&l=3D15).
>
> Cheers
> Lennart
>
> _______________________________________________
> 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

= --Apple-Mail=_35782B66-B96E-47C7-A3ED-B44AC0F51376-- --Apple-Mail=_27AC6148-F0F7-4118-9CDD-5E06C34FB1F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlraIOsACgkQY2o/VmzJ +KFKnA//bbN8ry3bFW/YSShfJfE1MrxOfYz/IlJyPM08Yl8ftDIPBkFKTHSK1MRF o+XRTfd3JjPYVsJ9JABke3xqm+kMHns6KIrkJO2BX1371XWWGgMNDVkb+EtzJpJ+ 5PsPQzfD+ozYbaAjsfDLJzvZjbvIEvyeNMSzQXIh/08EMO1dy1XzELV8LDcIrwum 5E6F2/R3g+3acFaRTB1w/ufns3B+Fb8LzVrIBjlV2/BEFM3SUZvX5e5ykTh57UGQ zOA2dj6cZtyjiFNvpNyd98CakYdc7sJpZwC9+reUhl/I5+Sc95dXNmEbQqdwhqDb GgtWUz1KHilqOlXjhpxSN/YPGgD9ev/421+q/Nocuuq4SAo4y4CnlqjphToWfD2u 1shD4caNXI7b3PajlaIt4H6lF3Ybeq9yoOSj/lOCLolmMa9a6Y52ToLR4BCxn5FW 7x840girRFJ6U+0iy/k0WdFYmvVoVtnySsfvLsxzIanv6+tppWUmONAPdL2wez3W zzg61M7lmnhy8wL38CEw88C5T7Ewrfl8pztai00VpoEyO7TKebJ08m8HPlsbRDWj Q04mi+ld0x7mVhDKQuM1Sji/7u3XpqoOasf0e/Z/jaFiBF36wB3V1azHuRPneEV/ arUpxXxkxN6PSNQodu/oQZb751VTAjpdGbKXkeDLTJuusIQ8teQ= =9ORW -----END PGP SIGNATURE----- --Apple-Mail=_27AC6148-F0F7-4118-9CDD-5E06C34FB1F6-- From nobody Fri Apr 20 10:41:16 2018 Return-Path: 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 EC771127137 for ; Fri, 20 Apr 2018 10:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Dbh92uDBQJCX for ; Fri, 20 Apr 2018 10:41:08 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937E612D87F for ; Fri, 20 Apr 2018 10:41:08 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id j18so6205833uae.12 for ; Fri, 20 Apr 2018 10:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KCDoLMB0Mkp8aWU5aFC7ekxCQl9gCBhUSmL6O8xrH8U=; b=j9c80ZIOVCN8VNdabtohxvBUocd6+DIxwTaVRtaekAp2h2+mfGI3Uv2M7X6EbZWtCH lKbZj7u3GDbE1dRtSeHZf782wn4WRs77IYK7vd3QGCArNvm4LDiUfo33zSk4NYFjZ6P3 bPZ+qvp4D1AVecZYWs47cojpN3cCXzqNNLdLccbWZa4KjlZ7jwbNvYoaxMDAW+MgOOx4 365qwaWNn9MV33zlKqweHMo92xpDXXKPZ6klqhOmVxH3gcv8LuocWXhRiFCjXiIdrd7q LL1T+rN8GShzLn7Jm0VK9YSui8tjJk+/gMfGsIlTgnHusbRl9sCKCo9sNTgX7A3ydsgs brsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KCDoLMB0Mkp8aWU5aFC7ekxCQl9gCBhUSmL6O8xrH8U=; b=ejd6QelDWRd+kKCDuYBoX9qs1sS2bj2JM5jn+G4zTOoYK72Y5vOPmUp5w8RAgCjS9c X/oyLpMqgB6h+xA5/+sEsloUwONS3sQKjjJvPuenic5jgwDqY7s0PUfm4aai3noWJNrn +aYE+DqDp7JY7u0erceZM+ArihHhCdvyUCS2p/HneUmnYQyEStGkhmpGMnY8xdde4Fn1 khiDgSJ1P5orMjleGxo8nRCRrvwGXFq8ZLs44BL5YVHMgU0lBxnwESs/9IVfQt6QYYN/ wVVB9TMDZdenw0gKqkBEkY1Eb2YEMepC8LP/mF0s8QnQwOqRFfiZzNVS18q4yRwveQRB BfFQ== X-Gm-Message-State: ALQs6tCcK+YEnxiQDy88dwlIqE97Wy8YjUYDVXkNErK1iPSnZqJRhGNt dH41EBzq8r7Hm8rGQ6Z2kpsvByVlbY2Gw8heaXjzCg== X-Google-Smtp-Source: AIpwx49Prli09TEM5mjY5AwkprayyLPL0CFJ5p+Pk/cUvdGtWF1YTswGJWTE3+qpkrfSjBA3Ppk+NrY5Ka23TpaqzUI= X-Received: by 10.159.41.99 with SMTP id t90mr8589584uat.127.1524246067186; Fri, 20 Apr 2018 10:41:07 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <7E9CBD87-6C00-4CF8-AEDE-D2AEFC3213FA@westhawk.co.uk> <03257894-7D79-463D-BC3A-5B388680A3E7@sn3rd.com> <0B04D27C-316A-41D2-91B9-01CD2A784D68@sn3rd.com> <8F091C3B-D150-4196-85DB-B5C42AD6E4F0@mozilla.com> In-Reply-To: <8F091C3B-D150-4196-85DB-B5C42AD6E4F0@mozilla.com> From: Justin Uberti Date: Fri, 20 Apr 2018 17:40:54 +0000 Message-ID: To: Nils Ohlmeier Cc: juberti=40google.com@dmarc.ietf.org, RTCWeb IETF Content-Type: multipart/alternative; boundary="001a114dfb38636805056a4b31fe" Archived-At: Subject: Re: [rtcweb] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 17:41:12 -0000 --001a114dfb38636805056a4b31fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 20, 2018 at 10:18 AM Nils Ohlmeier wrote: > > On Apr 20, 2018, at 07:48, Justin Uberti < > juberti=3D40google.com@dmarc.ietf.org> wrote: > > Small PR for improved text: > https://github.com/juberti/draughts/pull/100/files > > > I think this helps. > > I guess that the implementation is suppose to fall back to mode 3 (vs not > work at all) derives from the =E2=80=9CThis is the same as Mode 3,=E2=80= =A6=E2=80=9D part? > Correct. > The only option which comes to my mind to make this more explicit would b= e > to add another sentence like =E2=80=9CIf the applications HTTP traffic is= not > proxied it should fall back to Mode 3=E2=80=9D. > I thought about this but decided just to clarify the sentence where it refers to Mode 3, since adding an explicit sentence felt like belaboring the point. If you still feel this is unclear I could be convinced. > > Nils > > On Fri, Apr 20, 2018 at 5:50 AM Sean Turner wrote: > >> I=E2=80=99m going to go ahead and push this draft towards Adam (our AD) = and we=E2=80=99ll >> treat this as an IETF LC comment to get fixed up before the IESG telecha= t >> (i.e., Justin just throw a PR in for whatever change, but there=E2=80=99= s no need >> to spin a new version). >> >> spt >> >> > On Apr 19, 2018, at 21:10, Lennart Grahl > > wrote: >> > >> > On 20.04.2018 02:02, Justin Uberti wrote: >> >> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl > > >> >> wrote: >> >> >> >>> On 20.04.2018 01:29, Justin Uberti wrote: >> >>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier > > >> >>> wrote: >> >>>> >> >>>>> While I understand the arguments against adding more mode I still >> think >> >>>>> the paragraph describing Mode 4 is missing details and causes >> confusion >> >>>>> among implementers: >> >>>>> >> >>>>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D refers to a = HTTP proxy or a >> TURN >> >>>>> server. >> >>>>> >> >>>>> This can easily be improved by replacing the word =E2=80=9Cproxy= =E2=80=9D with =E2=80=9CHTTP >> >>>>> proxy=E2=80=9D everywhere in the Mode 4 paragraph. >> >>>>> >> >>>> >> >>>> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or >> RETURN >> >>>> proxy (SOCKS is specifically noted in the para). >> >>>> >> >>>>> >> >>>>> - It is unclear how an implementation should behave in the absence >> of >> >>> such >> >>>>> a proxy. >> >>>>> >> >>>>> I would suggest to add a sentence the implementation should not >> hand out >> >>>>> any candidates in the absence of a HTTP proxy. >> >>>>> >> >>>> >> >>>> This is a fair point. However, my take is that the behavior should >> be the >> >>>> same as Mode 3 in this case, as the web server already sees the >> client >> >>> IP. >> >>>> I could add a sentence to make this super clear. >> >>> >> >>> The web server, yes. But not the other peer. I don't think we can >> assume >> >>> trust towards the web server equals trust towards the other peer. I >> >>> would agree with Nils that it shouldn't hand out any candidates in >> this >> >>> case. >> >>> >> >> >> >> This is not unique to Mode 4. >> >> >> >> This scenario is discussed in detail in >> >> >> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5= .4 >> ; >> >> I don't think it needs special mention in this doc. >> > >> > Still, I see no possibility for the user to voice it's opinion in this >> > matter. However, that may simply be an issue for the browser vendors t= o >> > resolve (by providing additional browser settings - I think at least >> > Firefox does that already). >> > >> > Then it probably should be clarified because if I'm not mistaken Chrom= e >> > gets it wrong, too (no proxy =3D no candidates). Unless that fourth mo= de >> > does not actually map to mode 4 (see >> > >> https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_han= dling_policy.cc?q=3DrtcIPHandling&sq=3Dpackage:chromium&dr=3DCSs&l=3D15 >> ). >> > >> > Cheers >> > Lennart >> > >> > _______________________________________________ >> > 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 > --001a114dfb38636805056a4b31fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Apr 20, 2018 at 10:18 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

On Apr 20, 2018, at 07:48, Just= in Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

I think this= helps.

I guess that the implementation is suppose= to fall back to mode 3 (vs not work at all) derives from the =E2=80=9CThis= is the same as Mode 3,=E2=80=A6=E2=80=9D part?

Correct.
=C2=A0
T= he only option which comes to my mind to make this more explicit would be t= o add another sentence like =E2=80=9CIf the applications HTTP traffic is no= t proxied it should fall back to Mode 3=E2=80=9D.
<= div>
I thought about this but decided just to clarify the sen= tence where it refers to Mode 3, since adding an explicit sentence felt lik= e belaboring the point. If you still feel this is unclear I could be convin= ced.

=C2=A0 Nils
On Fri, Apr 20, 2018 at 5:50 AM Sean Turner <sean@sn3rd.com> wrote:
I=E2=80=99m going to go ahead and push this draft tow= ards Adam (our AD) and we=E2=80=99ll treat this as an IETF LC comment to ge= t fixed up before the IESG telechat (i.e., Justin just throw a PR in for wh= atever change, but there=E2=80=99s no need to spin a new version).

spt

> On Apr 19, 2018, at 21:10, Lennart Grahl <lennart.grahl@gmail.com> wrote:=
>
> On 20.04.2018 02:02, Justin Uberti wrote:
>> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <lennart.grahl@gmail.com>= ;
>> wrote:
>>
>>> On 20.04.2018 01:29, Justin Uberti wrote:
>>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <nohlmeier@mozilla.com>
>>> wrote:
>>>>
>>>>> While I understand the arguments against adding more m= ode I still think
>>>>> the paragraph describing Mode 4 is missing details and= causes confusion
>>>>> among implementers:
>>>>>
>>>>> - It is not clear if the word =E2=80=9Cproxy=E2=80=9D = refers to a HTTP proxy or a TURN
>>>>> server.
>>>>>
>>>>> This can easily be improved by replacing the word =E2= =80=9Cproxy=E2=80=9D with =E2=80=9CHTTP
>>>>> proxy=E2=80=9D everywhere in the Mode 4 paragraph.
>>>>>
>>>>
>>>> The proxy doesn't need to be a HTTP proxy; it could be= a SOCKS or RETURN
>>>> proxy (SOCKS is specifically noted in the para).
>>>>
>>>>>
>>>>> - It is unclear how an implementation should behave in= the absence of
>>> such
>>>>> a proxy.
>>>>>
>>>>> I would suggest to add a sentence the implementation s= hould not hand out
>>>>> any candidates in the absence of a HTTP proxy.
>>>>>
>>>>
>>>> This is a fair point. However, my take is that the behavio= r should be the
>>>> same as Mode 3 in this case, as the web server already see= s the client
>>> IP.
>>>> I could add a sentence to make this super clear.
>>>
>>> The web server, yes. But not the other peer. I don't think= we can assume
>>> trust towards the web server equals trust towards the other pe= er. I
>>> would agree with Nils that it shouldn't hand out any candi= dates in this
>>> case.
>>>
>>
>> This is not unique to Mode 4.
>>
>> This scenario is discussed in detail in
>> https://tools.iet= f.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4;
>> I don't think it needs special mention in this doc.
>
> Still, I see no possibility for the user to voice it's opinion in = this
> matter. However, that may simply be an issue for the browser vendors t= o
> resolve (by providing additional browser settings - I think at least > Firefox does that already).
>
> Then it probably should be clarified because if I'm not mistaken C= hrome
> gets it wrong, too (no proxy =3D no candidates). Unless that fourth mo= de
> does not actually map to mode 4 (see
> https://cs.chro= mium.org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q= =3DrtcIPHandling&sq=3Dpackage:chromium&dr=3DCSs&l=3D15). >
> Cheers
> Lennart
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--001a114dfb38636805056a4b31fe-- From nobody Fri Apr 20 18:11:19 2018 Return-Path: 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 652FA126E01 for ; Fri, 20 Apr 2018 18:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 70vGf3vPdTBe for ; Fri, 20 Apr 2018 18:11:17 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DD2126DED for ; Fri, 20 Apr 2018 18:11:16 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id m22-v6so11494414otf.8 for ; Fri, 20 Apr 2018 18:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XO1C/dlTjxNjA7KyVuzsPNPQOA2ttB/hw9WzHqyW3Io=; b=J6QaYvPLVGu4NuTEo4w4qmLGAj1eyZfYKSNBTLyz6bohViXliGAv0x2mgprm0hTwO7 I+zIj+NdeoxZTfutJbXksaQhxiy02OpuMxIQ4Yku0pcV7eHPTqsuKW6Ep+QWSHhPbBZB Sxz1oUkgQdbKgg2XbiFI8rCJILN7EqW3dijT3CmZcBiVnmslbiEma21fzP5x+RVd+azT qADp0HcUedCbCuvpZuPlF4XI/S+7qZJcKaNBfb9zQxaMU/+cVlQUeccJ66XDT8TSkxs0 WFU4AXtKkIE4C42hWgyr/tG7yIURMEw0ryag0NLjjb8Zk95MSMdb/6nAg94f8GRo0u7+ Edtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XO1C/dlTjxNjA7KyVuzsPNPQOA2ttB/hw9WzHqyW3Io=; b=YDUpOwR6T2ZOzu2iPj2o/I/bmhdEfa3hwLuGaB4mOz+q6GRJ72V+WZLJzibGDCrVbN ibCrC2VD5h5+zg9pbz5Pnz5F4j0/3ZXdSR4JHz5gknxhqb/PiZp6ps3cuHi+SWA/3JV7 fFuUVi/zVFajQj2bxC3zDtIGHLgwxxqUP/1YLBTYqarS/SByx2cVQlOpWiV6tcV1Ki1H 0FiwqSBheHzRy44IZ1NcYO8glb+92sa5PSJhFGy9AJKEySzMEfJbrKMZDTWfX/F0h0r3 B+OqOlSwiR3BOrfJKn3ZIF3M4l5P0OazS0srIEwxsckb6pHFjAjInRa4XGzpqypJB2Vo +gDw== X-Gm-Message-State: ALQs6tD4KUq6zqq6RMLRKVbPGpYrpsVd7wB2tOh3AfNCNuYxdchvpbYQ PsjWnpIC9PxlOcCKo8lRI8zEN2GH0KNzf9WRFTOwK3KckwE= X-Google-Smtp-Source: AIpwx488IC6MawR0PknOz9Iv2+GMneVO23eiRrLIGJMHLL64fdP2ZLXUXlqBMq0yr9LUn9kpkQIM2DZii6AlhuvGnms= X-Received: by 2002:a9d:23f6:: with SMTP id t109-v6mr8639621otb.44.1524273076219; Fri, 20 Apr 2018 18:11:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Fri, 20 Apr 2018 18:10:35 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 20 Apr 2018 18:10:35 -0700 Message-ID: To: Sean Turner Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000003fc880056a517b10" Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 01:11:18 -0000 --0000000000003fc880056a517b10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2018 at 6:45 AM, Sean Turner wrote: > The WGLC for this document has ended. I think it was really good that @ > IETF101 the IdP hackathon happened because it looked like they might have > uncovered something to be changed in our document and possibly in the > webrtc-pc draft; see the [0] thread. As the Shepherd trying to drive thi= s > to closure, we need to we need to decide what changes might be made in > draft-ietf-rtcweb-security-arch. In that thread, I saw two things that > we might change (both from mt): > > 0) More text to address a linkability concern: > > As a practical matter, if the browser were to use the same certificate > for multiple origins, then it would create a massive privacy problem > that enables linkability (aka user tracking). I couldn't find that > written down, but I thought it was. If it isn't written down, then we > should correct that. > Isn't this the relevant text: " API Requirement: Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin. (This avoids creating a super-cookie.) " > I actually think this is basically covered here: > https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.1 > But want to make sure others agree: > > 1) Tweak protocol to include an identifier to prevent reuse of assertion > on every RTCPeerConnection: > > More complex sites frequently generate multiple RTCPeerConnection > instances for their communications, especially for group > conversations. If the browser requests an assertion once and they use > that value for every RTCPeerConnection, then that's OK. From my > perspective, I would be happy modifying the protocol to include an > identifier and prevent that; for this the IdP can use caching or its > local storage. > > So, what would that look like? > Wouldn't it be sufficient to include the tls-id in the identity binding? -Ekr > > > Did I miss anything else that needs to be addressed? > > spt > > [0] https://mailarchive.ietf.org/arch/msg/rtcweb/ > 2r2u20UQIKwNeY1PsYFrDw7jXEw > > > On Mar 12, 2018, at 19:08, Sean Turner wrote: > > > > All, > > > > This is the WGLC for the =E2=80=9CWebRTC Security Architecture=E2=80=9D= draft available > @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. Please > review the draft and send your comments to this list by 2359UTC on April > 6th, 2018. > > > > Note the gh repo is here: > > https://github.com/rtcweb-wg/security-arch > > > > Thanks, > > C/T/S > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000003fc880056a517b10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 12, 2018 at 6:45 AM, Sean Turner <sean@sn3rd.com> wrote:
The WGLC for this document has = ended.=C2=A0 I think it was really good that @ IETF101 the IdP hackathon ha= ppened because it looked like they might have uncovered something to be cha= nged in our document and possibly in the webrtc-pc draft; see the [0] threa= d.=C2=A0 As the Shepherd trying to drive this to closure, we need to we nee= d to decide what changes might be made in draft-ietf-rtcweb-security-a= rch.=C2=A0 In that thread, I saw two things that we might change (both from= mt):

0) More text to address a linkability concern:

=C2=A0 As a practical matter, if the browser were to use the same certifica= te
=C2=A0 for multiple origins, then it would create a massive privacy problem=
=C2=A0 that enables linkability (aka user tracking).=C2=A0 I couldn't f= ind that
=C2=A0 written down, but I thought it was.=C2=A0 If it isn't written do= wn, then we
=C2=A0 should correct that.

Isn't t= his the relevant text:
"
   API =
Requirement:  Unless the user specifically configures an external
      key pair, different key pairs MUST be used for each origin.  (This
      avoids creating a super-cookie.)
"

=C2=A0
I actually think this is basically covered here:
https://tools.ietf.org/html/<= wbr>draft-ietf-rtcweb-security-10#section-4.4.1
But want to make sure others agree:

1) Tweak protocol to include an identifier to prevent reuse of assertion on= every RTCPeerConnection:

=C2=A0 More complex sites frequently generate multiple RTCPeerConnection =C2=A0 instances for their communications, especially for group
=C2=A0 conversations.=C2=A0 If the browser requests an assertion once and t= hey use
=C2=A0 that value for every RTCPeerConnection, then that's OK.=C2=A0 Fr= om my
=C2=A0 perspective, I would be happy modifying the protocol to include an =C2=A0 identifier and prevent that; for this the IdP can use caching or its=
=C2=A0 local storage.

So, what would that look like?

Wouldn&#= 39;t it be sufficient to include the tls-id in the identity binding?
<= div>
-Ekr




Did I miss anything else that needs to be addressed?

spt

[0] https://mailarchive.ietf= .org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7jXEw

> On Mar 12, 2018, at 19:08, Sean Turner <sean@sn3rd.com> wrote:
>
> All,
>
> This is the WGLC for the =E2=80=9CWebRTC Security Architecture=E2=80= =9D draft available @ https://datatracke= r.ietf.org/doc/draft-ietf-rtcweb-security/.=C2=A0 Please revi= ew the draft and send your comments to this list by 2359UTC on April 6th, 2= 018.
>
> Note the gh repo is here:
> https://github.com/rtcweb-wg/security-arch >
> Thanks,
> C/T/S

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--0000000000003fc880056a517b10-- From nobody Sun Apr 22 15:47:18 2018 Return-Path: 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 12B22126FDC for ; Sun, 22 Apr 2018 15:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.486 X-Spam-Level: X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PCg1epUclpKj for ; Sun, 22 Apr 2018 15:47:13 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628C71200FC for ; Sun, 22 Apr 2018 15:47:13 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id w4-v6so15203361ote.12 for ; Sun, 22 Apr 2018 15:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tZOgi1Gdxp9sKWkVmlkcWo3EPYOBPETT6FD7ByGnU+M=; b=Eyof0l/a+3jCWyYlxLkxNk9OdhK7KD3lC/CiYPFisap5xwviuZrSROAGteYKXdP4qF k9BH9xN93K2md0ZcnpR6aMoSHd7IV+Rmrvrl4prkrscrYGOBRLfBxLWLXbL32dxBTuZc RKHmonLhdlXozGroDWTZF3Z089ACVGY+lSj2kkYIssBA8AGUAVLX5hi0+V0JKd/mwHu6 rJv184omlD+Z5Pns9v1IE1mOqYjDXvKIXuHT4jAuCroqma1jVvJLfJhfrPVUQgkijymQ g0tOn9TVquUmBNCwDgS2CK1KTeYjN6cwhHv3IiRHX7t7yfb2YmONlkeDBX2T4Ygsqw6E exfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tZOgi1Gdxp9sKWkVmlkcWo3EPYOBPETT6FD7ByGnU+M=; b=N5FAGitVgqSv6kc8Zt+VBoMPH+kZ+Q4IDuyCfe5KOIXUpRHQ02AA5hOq36cR8jOwIC ngNC9jQmq3JAezd9vrg4Lh7SncVr38wzjviUGlG8v+MgAuwGxopCA/mmhvKFcZSCHkOO v8SDQ1s/vY1TRJp7C2ZU8a+4ZPH1AKKECv770F2dCeJoNJ/Vgf5wK08f6YhhwPvTlSZK k2R6WcNUhI+0Zx5P8MlXri2gY9NVXDTWm9Wy3Jm15L1vTKLIPZi8a3ffM1MpmtsgfO4c i9t27mZiRkj1iUJEQcbCk2v/dmUa/pFbAOQlVaO1B5bCy0XEdkR8OAozx8IfDnmD2mtQ IXOQ== X-Gm-Message-State: ALQs6tDlnkBTLlbwdrl9pG2Acuq5cSDyfqzUe9OcMqYf+EpxP8A4KVXh +3/bpG3NnbBeVXORn4p4FivrhyfFnAjtvwXUSDH5pA== X-Google-Smtp-Source: AIpwx49tjmNIvvGw+UKgr4/YvfAmoJySfgdM+zc9ED0h0QjPlUbwwcDfSWkRYeKVgLm6U5V4FYdR70muyhyocJ6Gksk= X-Received: by 2002:a9d:524d:: with SMTP id q13-v6mr13016072otg.241.1524437232636; Sun, 22 Apr 2018 15:47:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:29ce:0:0:0:0:0 with HTTP; Sun, 22 Apr 2018 15:47:12 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 23 Apr 2018 08:47:12 +1000 Message-ID: To: Eric Rescorla Cc: Sean Turner , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 22:47:16 -0000 tls-id is connection-based (i.e., it applies to a single bundle), whereas identity is session-based. That was my initial thought, but then we have to deal with the 1:N problem there. The simplest approach might be to move a=3Didentity to the bundle, but that leads to some interesting downstream effects. You probably want to avoid having multiple identities in the same RTCPeerConnection, for instance. On Sat, Apr 21, 2018 at 11:10 AM, Eric Rescorla wrote: > > > On Thu, Apr 12, 2018 at 6:45 AM, Sean Turner wrote: >> >> The WGLC for this document has ended. I think it was really good that @ >> IETF101 the IdP hackathon happened because it looked like they might hav= e >> uncovered something to be changed in our document and possibly in the >> webrtc-pc draft; see the [0] thread. As the Shepherd trying to drive th= is >> to closure, we need to we need to decide what changes might be made in >> draft-ietf-rtcweb-security-arch. In that thread, I saw two things that = we >> might change (both from mt): >> >> 0) More text to address a linkability concern: >> >> As a practical matter, if the browser were to use the same certificate >> for multiple origins, then it would create a massive privacy problem >> that enables linkability (aka user tracking). I couldn't find that >> written down, but I thought it was. If it isn't written down, then we >> should correct that. > > > Isn't this the relevant text: > " > > API Requirement: Unless the user specifically configures an external > key pair, different key pairs MUST be used for each origin. (This > avoids creating a super-cookie.) > > " > > >> >> I actually think this is basically covered here: >> https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.1 >> But want to make sure others agree: >> >> 1) Tweak protocol to include an identifier to prevent reuse of assertion >> on every RTCPeerConnection: >> >> More complex sites frequently generate multiple RTCPeerConnection >> instances for their communications, especially for group >> conversations. If the browser requests an assertion once and they use >> that value for every RTCPeerConnection, then that's OK. From my >> perspective, I would be happy modifying the protocol to include an >> identifier and prevent that; for this the IdP can use caching or its >> local storage. >> >> So, what would that look like? > > > Wouldn't it be sufficient to include the tls-id in the identity binding? > > -Ekr > >> >> >> >> Did I miss anything else that needs to be addressed? >> >> spt >> >> [0] >> https://mailarchive.ietf..org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7jXE= w >> >> > On Mar 12, 2018, at 19:08, Sean Turner wrote: >> > >> > All, >> > >> > This is the WGLC for the =E2=80=9CWebRTC Security Architecture=E2=80= =9D draft available >> > @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. Pleas= e >> > review the draft and send your comments to this list by 2359UTC on Apr= il >> > 6th, 2018. >> > >> > Note the gh repo is here: >> > https://github.com/rtcweb-wg/security-arch >> > >> > Thanks, >> > C/T/S >> >> _______________________________________________ >> 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 > From nobody Mon Apr 23 05:35:09 2018 Return-Path: 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 D31F1126C89 for ; Mon, 23 Apr 2018 05:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 ajqlTI189Dp9 for ; Mon, 23 Apr 2018 05:35:00 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 42D09129515 for ; Mon, 23 Apr 2018 05:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1524486892; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Vj2LrzBg4awVumFxgFqSG1QbTUgbOYwJp9NVeRiM8V4=; b=LoRoP73qZuwbCwCWrLaMLL8VwbA3V6wSLRMo6I4Gp9rDarWQGjdbEUD5fklR0hN6 Gqz7Mm0TwqZIC97Mos7ZBF1yK9hs6HmLos7o/j25+pqR1TNPatwECZLmSgwa9WI/ FjC5ENG734cpGVfh2L54QGAyx+eE9UhUCFm8qgz6+dA=; X-AuditID: c1b4fb25-8a3ff70000006561-5a-5addd2ec0322 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D1.A6.25953.CE2DDDA5; Mon, 23 Apr 2018 14:34:52 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0382.000; Mon, 23 Apr 2018 14:34:51 +0200 From: Christer Holmberg To: Martin Thomson , Eric Rescorla CC: RTCWeb IETF Thread-Topic: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) Thread-Index: AQHT2ovhiDchN2k/30+uRrZXdqGfAqQOWzwA Date: Mon, 23 Apr 2018 12:34:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [131.160.50.130] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7k+6bS3ejDLqOy1useH2O3eLamX+M Fmv/tbM7MHvsnHWX3WPJkp9MHpMftzEHMEdx2aSk5mSWpRbp2yVwZUybsZepoFW14tdHtgbG z7JdjJwcEgImEo8WfGftYuTiEBI4wihxZNdzNghnMaPE16srGbsYOTjYBCwkuv9pgzSICHhL 7Ds4gRXEZhZQlPiyfD4biC0s0MUosedHHkiviEA3o8SJHffZIRqMJFpeLmcEsVkEVCWaF3wA a+AVsJaY9fUsC8Syv4wSl17dYwFJcAoESmzfMRdsA6OAmMT3U2uYILaJS9x6Mp8J4mwBiSV7 zjND2KISLx//A6sXFdCT2HDiNjvI0RICShK3NzhBtOpJ3Jg6hQ3Ctpb4/biDHcLWlli28DUz xD2CEidnPmGZwCg+C8m2WUjaZyFpn4WkfRaS9gWMrKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJS SzYxAmPw4JbfqjsYL79xPMQowMGoxMO76cDdKCHWxLLiytxDjBIczEoivB7bgEK8KYmVValF +fFFpTmpxYcYpTlYlMR5H5pvjhISSE8sSc1OTS1ILYLJMnFwSjUwunmv+Wb3tcCK6RV/4p2v 2vnLnhnLLUjcvWfTafcH93en3//0sdPF/caHgO6/C+4+2vps/fNwptuSiUVfN2QH/Oqf8EPr N3s119a07+mWVWXtSdeUXx7bdvvMzh6F7ClzezdULg7UubW1dGWdkLW89edFSs/Xrt3/XPb2 imlHXq2OfhHUbj5nfokSS3FGoqEWc1FxIgAehgtkvQIAAA== Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 12:35:08 -0000 Hi, A couple of questions on the SDP identity attribute. Q1: --- The draft lacks the offer/answer procedure sections (generate offer, generate answer, modify session etc) for the attribute, which I think should be added. My question is regarding the following statement, which seems to indicate that the attribute is only used in offers: "Implementations SHOULD only include a single identity attribute in an offer=B2 (there is no text about including the attribute in an answer) However, in draft-ietf-rtcweb-sdp it is included in both the offer and answer. Q2: --- Also, the mux category is missing (draft-ietf-mmusic-sdp-mux-attributes also covers session-level attributes). I assume it is =B3NORMAL=B2. Regards, Christer =20 On 23/04/18 01:47, "rtcweb on behalf of Martin Thomson" wrote: >tls-id is connection-based (i.e., it applies to a single bundle), >whereas identity is session-based. That was my initial thought, but >then we have to deal with the 1:N problem there. The simplest >approach might be to move a=3Didentity to the bundle, but that leads to >some interesting downstream effects. You probably want to avoid >having multiple identities in the same RTCPeerConnection, for >instance. > >On Sat, Apr 21, 2018 at 11:10 AM, Eric Rescorla wrote: >> >> >> On Thu, Apr 12, 2018 at 6:45 AM, Sean Turner wrote: >>> >>> The WGLC for this document has ended. I think it was really good that >>>@ >>> IETF101 the IdP hackathon happened because it looked like they might >>>have >>> uncovered something to be changed in our document and possibly in the >>> webrtc-pc draft; see the [0] thread. As the Shepherd trying to drive >>>this >>> to closure, we need to we need to decide what changes might be made in >>> draft-ietf-rtcweb-security-arch. In that thread, I saw two things >>>that we >>> might change (both from mt): >>> >>> 0) More text to address a linkability concern: >>> >>> As a practical matter, if the browser were to use the same >>>certificate >>> for multiple origins, then it would create a massive privacy problem >>> that enables linkability (aka user tracking). I couldn't find that >>> written down, but I thought it was. If it isn't written down, then >>>we >>> should correct that. >> >> >> Isn't this the relevant text: >> " >> >> API Requirement: Unless the user specifically configures an external >> key pair, different key pairs MUST be used for each origin. (This >> avoids creating a super-cookie.) >> >> " >> >> >>> >>> I actually think this is basically covered here: >>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.1 >>> But want to make sure others agree: >>> >>> 1) Tweak protocol to include an identifier to prevent reuse of >>>assertion >>> on every RTCPeerConnection: >>> >>> More complex sites frequently generate multiple RTCPeerConnection >>> instances for their communications, especially for group >>> conversations. If the browser requests an assertion once and they >>>use >>> that value for every RTCPeerConnection, then that's OK. From my >>> perspective, I would be happy modifying the protocol to include an >>> identifier and prevent that; for this the IdP can use caching or its >>> local storage. >>> >>> So, what would that look like? >> >> >> Wouldn't it be sufficient to include the tls-id in the identity binding? >> >> -Ekr >> >>> >>> >>> >>> Did I miss anything else that needs to be addressed? >>> >>> spt >>> >>> [0] >>>=20 >>>https://mailarchive.ietf..org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7jXE >>>w >>> >>> > On Mar 12, 2018, at 19:08, Sean Turner wrote: >>> > >>> > All, >>> > >>> > This is the WGLC for the =B3WebRTC Security Architecture=B2 draft >>>available >>> > @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. >>>Please >>> > review the draft and send your comments to this list by 2359UTC on >>>April >>> > 6th, 2018. >>> > >>> > Note the gh repo is here: >>> > https://github.com/rtcweb-wg/security-arch >>> > >>> > Thanks, >>> > C/T/S >>> >>> _______________________________________________ >>> 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 From nobody Thu Apr 26 17:26:47 2018 Return-Path: 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 468FC12D810 for ; Thu, 26 Apr 2018 17:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 y5rscrEykYqW for ; Thu, 26 Apr 2018 17:26:42 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D2D124B18 for ; Thu, 26 Apr 2018 17:26:42 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id f1-v6so208854qtj.6 for ; Thu, 26 Apr 2018 17:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7FIpgw4UvyoxMlDvqkLT2lAFjoj1iCeMTOswmqOPG4o=; b=TJZ1kXv6FrOIu7V58ulhNL1iyCQYU9N/Uoysh+nT4HO9S4yCWNeZ06C+hk5dNO5Muk DM5gee/S/JquVBRQh/TOXdW7psCKhsDJHdk5k5HVht0fi/tg3bE7vIcs5WWm1FN5wMJ5 haCLCbsUCHYEcHe7kQAk3xpkQe2mU7djZMm4Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7FIpgw4UvyoxMlDvqkLT2lAFjoj1iCeMTOswmqOPG4o=; b=W8zfdcEntykEWDgmS084u7qeRbSAqd41UTqBT3ij/R6ewW2YxhykGnmSYWRJu8Mn+8 2mbaki5vgUIDFGwNcVSGRAmv1I6ak/Kor5UxHga81hhABgt0rpZV4GXEPzmwA6KJi7vu LuKQfhDnaGjQc09PRIZ+W5Dfo45Qwj/hjOPxlbKiZ1ERxi7Fr6j7OyCgUjp6DCAldw79 +eoVxfcURav0Rnq/l47IcEN8pZpkZ3mbWnsQsH8ap4iw7rjebvVziZSJwfYDDesEiGXI OrPqXuz/N2iXwoi3ctA4YgpWhF4pr5TYc3vuM0zmw9ZoFFgXxT6llnHDpNObkppv5G0s lvzQ== X-Gm-Message-State: ALQs6tBP7Mt2diwSmV7UhMRCWPMdjdAQ7GtDEdeA6FdrqQ4dXwrJAzl3 /bIZjtlVPdX4EtlVRyN46P3dNw== X-Google-Smtp-Source: AB8JxZqawkoNlvme+unySAZiuxAHCxH7I0wEbw4QImRzHfn26UvaECzFcKaTKgp6J6URbxZaYhX6IQ== X-Received: by 2002:aed:356a:: with SMTP id b39-v6mr184934qte.230.1524788801391; Thu, 26 Apr 2018 17:26:41 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id j42-v6sm107951qtj.46.2018.04.26.17.26.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Apr 2018 17:26:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: Date: Thu, 26 Apr 2018 20:26:38 -0400 Cc: Martin Thomson , Eric Rescorla , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christer Holmberg X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 00:26:45 -0000 > On Apr 23, 2018, at 08:34, Christer Holmberg = wrote: >=20 > Hi, >=20 > A couple of questions on the SDP identity attribute. >=20 > Q1: > --- >=20 > The draft lacks the offer/answer procedure sections (generate offer, > generate answer, modify session etc) for the attribute, which I think > should be added. My question is regarding the following statement, = which > seems to indicate that the attribute is only used in offers: >=20 > "Implementations SHOULD only include a single identity attribute in = an > offer=C2=B2 (there is no text about including the attribute in an = answer) This is about what to do if you include a=3Didentity not about whether = to include it. > However, in draft-ietf-rtcweb-sdp it is included in both the offer and > answer. I think that draft-ietf-rtcweb-sdp includes them in both the offer and = the answer because the examples are using the WEBRTC Identity mechanism. = I think this is consistent with what is in both draft-ietf-rtcweb-sdp = and draft-ietf-rtcweb-jsep: If WebRTC identity is being used, an "a=3Didentity" line as described in [I-D.ietf-rtcweb-security-arch], Section 5. > Q2: > --- >=20 > Also, the mux category is missing = (draft-ietf-mmusic-sdp-mux-attributes > also covers session-level attributes). I assume it is =C2=B3NORMAL=C2=B2= . I think this mans adding: Mux Category: NORMAL to the IANA registration? spt > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 23/04/18 01:47, "rtcweb on behalf of Martin Thomson" > wrote: >=20 >> tls-id is connection-based (i.e., it applies to a single bundle), >> whereas identity is session-based. That was my initial thought, but >> then we have to deal with the 1:N problem there. The simplest >> approach might be to move a=3Didentity to the bundle, but that leads = to >> some interesting downstream effects. You probably want to avoid >> having multiple identities in the same RTCPeerConnection, for >> instance. >>=20 >> On Sat, Apr 21, 2018 at 11:10 AM, Eric Rescorla wrote: >>>=20 >>>=20 >>> On Thu, Apr 12, 2018 at 6:45 AM, Sean Turner wrote: >>>>=20 >>>> The WGLC for this document has ended. I think it was really good = that >>>> @ >>>> IETF101 the IdP hackathon happened because it looked like they = might >>>> have >>>> uncovered something to be changed in our document and possibly in = the >>>> webrtc-pc draft; see the [0] thread. As the Shepherd trying to = drive >>>> this >>>> to closure, we need to we need to decide what changes might be made = in >>>> draft-ietf-rtcweb-security-arch. In that thread, I saw two things >>>> that we >>>> might change (both from mt): >>>>=20 >>>> 0) More text to address a linkability concern: >>>>=20 >>>> As a practical matter, if the browser were to use the same >>>> certificate >>>> for multiple origins, then it would create a massive privacy = problem >>>> that enables linkability (aka user tracking). I couldn't find = that >>>> written down, but I thought it was. If it isn't written down, = then >>>> we >>>> should correct that. >>>=20 >>>=20 >>> Isn't this the relevant text: >>> " >>>=20 >>> API Requirement: Unless the user specifically configures an = external >>> key pair, different key pairs MUST be used for each origin. = (This >>> avoids creating a super-cookie.) >>>=20 >>> " >>>=20 >>>=20 >>>>=20 >>>> I actually think this is basically covered here: >>>> = https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.1 >>>> But want to make sure others agree: >>>>=20 >>>> 1) Tweak protocol to include an identifier to prevent reuse of >>>> assertion >>>> on every RTCPeerConnection: >>>>=20 >>>> More complex sites frequently generate multiple RTCPeerConnection >>>> instances for their communications, especially for group >>>> conversations. If the browser requests an assertion once and they >>>> use >>>> that value for every RTCPeerConnection, then that's OK. =46rom my >>>> perspective, I would be happy modifying the protocol to include an >>>> identifier and prevent that; for this the IdP can use caching or = its >>>> local storage. >>>>=20 >>>> So, what would that look like? >>>=20 >>>=20 >>> Wouldn't it be sufficient to include the tls-id in the identity = binding? >>>=20 >>> -Ekr >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Did I miss anything else that needs to be addressed? >>>>=20 >>>> spt >>>>=20 >>>> [0] >>>>=20 >>>> = https://mailarchive.ietf..org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7jXE >>>> w >>>>=20 >>>>> On Mar 12, 2018, at 19:08, Sean Turner wrote: >>>>>=20 >>>>> All, >>>>>=20 >>>>> This is the WGLC for the =C2=B3WebRTC Security Architecture=C2=B2 = draft >>>> available >>>>> @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. >>>> Please >>>>> review the draft and send your comments to this list by 2359UTC on >>>> April >>>>> 6th, 2018. >>>>>=20 >>>>> Note the gh repo is here: >>>>> https://github.com/rtcweb-wg/security-arch >>>>>=20 >>>>> Thanks, >>>>> C/T/S >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 26 18:02:52 2018 Return-Path: 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 3C29412D77E for ; Thu, 26 Apr 2018 18:02:51 -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 O__Lma11Jurp for ; Thu, 26 Apr 2018 18:02:49 -0700 (PDT) Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (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 68D3D124BE8 for ; Thu, 26 Apr 2018 18:02:49 -0700 (PDT) Received: from smtp29.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8F58924F3F; Thu, 26 Apr 2018 21:02:45 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 233C324F0D; Thu, 26 Apr 2018 21:02:45 -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:587 (trex/5.7.12); Thu, 26 Apr 2018 21:02:45 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_137ABF58-19D3-426A-AC9A-5CB8E7473160" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Thu, 26 Apr 2018 19:02:43 -0600 Cc: RTCWeb IETF Message-Id: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> References: To: Sean Turner X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 01:02:51 -0000 --Apple-Mail=_137ABF58-19D3-426A-AC9A-5CB8E7473160 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 12, 2018, at 7:45 AM, Sean Turner wrote: >=20 > 1) Tweak protocol to include an identifier to prevent reuse of = assertion on every RTCPeerConnection: >=20 > More complex sites frequently generate multiple RTCPeerConnection > instances for their communications, especially for group > conversations. If the browser requests an assertion once and they = use > that value for every RTCPeerConnection, then that's OK. =46rom my > perspective, I would be happy modifying the protocol to include an > identifier and prevent that; for this the IdP can use caching or its > local storage. >=20 > So, what would that look like? It=E2=80=99s not clear to me what the problem we are solving here is. = Who are we trying to stop from reusing an assertion and why. The = assertion is already bound to the specific private key and specific web = origin. The IdP can bind it to a narrow time range if the IdP wants ( = most do). I=E2=80=99m not seeing the big difference from reusing an = assertion vs. asking the for a bunch of them. The protocol that users = the assertion may end up forking the same assertion to many places = regardless of what the browser does.=20 Changing this so that the IdP see how many PeerConnections are formed = seems like it just reveal more usage information to the IdP and does not = help security. Assuming I am just not getting the problem and we do want to solve this = =E2=80=A6 I is not clear to me how to make this all work with tls-id due = to all the bundle issues. Another approach would the browser greater a = GUID for the PeerConnection and that is passed in the IdP proxy code and = the IdP can bind it into the assertion or not but if it does bind into = the assertion, then the browser will only validate the assertion on the = PeerConnection with matching GUID. This is probably wrong and half baked = as I don=E2=80=99t really get the problem.=20 --Apple-Mail=_137ABF58-19D3-426A-AC9A-5CB8E7473160 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 12, 2018, at 7:45 AM, Sean Turner <sean@sn3rd.com> = wrote:

1) Tweak protocol to include an = identifier to prevent reuse of assertion on every = RTCPeerConnection:

 More complex sites frequently generate multiple = RTCPeerConnection
 instances for their communications, especially for = group
 conversations.  If the browser requests an = assertion once and they use
 that value for every RTCPeerConnection, then that's OK. =  =46rom my
 perspective, I would be happy modifying the protocol to = include an
 identifier and prevent that; for this the IdP can use = caching or its
 local storage.

So, what would that look like?

It=E2=80=99s not clear to me what the problem = we are solving here is. Who are we trying to stop from reusing an = assertion and why. The assertion is already bound to the specific = private key and specific web origin. The IdP can bind it to a narrow = time range if the IdP wants ( most do). I=E2=80=99m not seeing the big = difference from reusing an assertion vs. asking the for a bunch of them. = The protocol that users the assertion may end up forking the same = assertion to many places regardless of what the browser = does. 

Changing this so that the IdP see how many PeerConnections = are formed seems like it just reveal more usage information to the IdP = and does not help security.

Assuming I am just not getting the problem and we do want to = solve this =E2=80=A6 I is not clear to me how to make this all work with = tls-id due to all the bundle issues. Another approach would the browser = greater a GUID for the PeerConnection and that is passed in the IdP = proxy code and the IdP can bind it into the assertion or not but if it = does bind into the assertion, then the browser will only validate the = assertion on the PeerConnection with matching GUID. This is probably = wrong and half baked as I don=E2=80=99t really get the = problem. 


= --Apple-Mail=_137ABF58-19D3-426A-AC9A-5CB8E7473160-- From nobody Thu Apr 26 23:10:46 2018 Return-Path: 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 3DFBB12D953 for ; Thu, 26 Apr 2018 23:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 YFRAxt1SZszh for ; Thu, 26 Apr 2018 23:10:42 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 90D8812D94B for ; Thu, 26 Apr 2018 23:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1524809438; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nnq4Z4okAeMaCbIVMepLOKu04vYEqm+1JPWKufJOVps=; b=YT77rb88IBhDtZtcA75CIXLzbuAV8khSYcB6vu9Qz4RufIw8iSc53+xMLwf4FZV+ 1XpZb8+4wb9nPrMUCl2bJFgOJDUNYW6Ls/viIO1ySduWNedwWdQ3KZ4ztwZIz1MH cuSZRixxFvcV2hGDk67VPq7o/xXoL8iD+OZwjzl1ris=; X-AuditID: c1b4fb2d-9d1ff700000068bb-66-5ae2bedecfd4 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.AF.26811.EDEB2EA5; Fri, 27 Apr 2018 08:10:38 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0382.000; Fri, 27 Apr 2018 08:10:37 +0200 From: Christer Holmberg To: Sean Turner CC: Martin Thomson , Eric Rescorla , RTCWeb IETF Thread-Topic: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) Thread-Index: AQHT2ovhiDchN2k/30+uRrZXdqGfAqQOWzwAgAVK9ACAAJMRAA== Date: Fri, 27 Apr 2018 06:10:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [131.160.50.130] Content-Type: text/plain; charset="euc-kr" Content-ID: <876CC9F63B4F1C4EBED6DC0D462208B7@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7ge69fY+iDPa+F7JY8focu8W1M/8Y Ldb+a2e3uLKqkdmBxWPnrLvsHkuW/GTymPy4jdnj4EHGAJYoLpuU1JzMstQifbsEroynVyYy FpxyqehY/Z+5gfGFUxcjJ4eEgInEuZPtbF2MXBxCAkcYJZonzmKBcBYzSkya8BDI4eBgE7CQ 6P6nDdIgIqAg0XT0ASuIzSyQI7HsTysLiC0s0MUosedHHkiviEA3o8SJHffZIRqcJJbu7AGz WQRUJf592wRm8wpYS0w/vIYdYtkjJonJj/sZQRKcArYSW0/1sIHYjAJiEt9PrWGC2CYucevJ fCaIswUkluw5zwxhi0q8fPwP7CJRAT2JDSdus4McLSGgJHF7gxNEq5bElx/72EDCzEB7/06x gAgrSkzpfgh1jqDEyZlPWCYwis9CsmwWku5ZCN2zkHTPQtK9gJF1FaNocWpxcW66kbFealFm cnFxfp5eXmrJJkZgTB7c8lt3B+Pq146HGAU4GJV4eI9vfhQlxJpYVlyZe4hRgoNZSYR3x+2H UUK8KYmVValF+fFFpTmpxYcYpTlYlMR59VbtiRISSE8sSc1OTS1ILYLJMnFwSjUwqki77Zae U/L23cwtt7Jn+b19MqP0u6zk6+1MBrHuERo/Pry8NzHsP29+q4VN+ko+pwezJgc/8/3VpXI0 vPDVrKi3xrUXbZSesJ8SVVdz5ZtXcP/VbafQJZorf/B89q3gWdKTFLl2h0gzN8eXw217H4fM eae9etLW9pOCv/fquqif8lrH5tTSoMRSnJFoqMVcVJwIANqKxYnFAgAA Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 06:10:45 -0000 SGksDQoNCj4+QSBjb3VwbGUgb2YgcXVlc3Rpb25zIG9uIHRoZSBTRFAgaWRlbnRpdHkgYXR0cmli dXRlLg0KPj4gDQo+PiBRMToNCj4+IC0tLQ0KPj4gDQo+PiBUaGUgZHJhZnQgbGFja3MgdGhlIG9m ZmVyL2Fuc3dlciBwcm9jZWR1cmUgc2VjdGlvbnMgKGdlbmVyYXRlIG9mZmVyLA0KPj4gZ2VuZXJh dGUgYW5zd2VyLCBtb2RpZnkgc2Vzc2lvbiBldGMpIGZvciB0aGUgYXR0cmlidXRlLCB3aGljaCBJ IHRoaW5rDQo+PiBzaG91bGQgYmUgYWRkZWQuIE15IHF1ZXN0aW9uIGlzIHJlZ2FyZGluZyB0aGUg Zm9sbG93aW5nIHN0YXRlbWVudCwgd2hpY2gNCj4+IHNlZW1zIHRvIGluZGljYXRlIHRoYXQgdGhl IGF0dHJpYnV0ZSBpcyBvbmx5IHVzZWQgaW4gb2ZmZXJzOg0KPj4gDQo+PiAgIkltcGxlbWVudGF0 aW9ucyBTSE9VTEQgb25seSBpbmNsdWRlIGEgc2luZ2xlIGlkZW50aXR5IGF0dHJpYnV0ZSBpbiBh bg0KPj4gb2ZmZXKp9yAodGhlcmUgaXMgbm8gdGV4dCBhYm91dCBpbmNsdWRpbmcgdGhlIGF0dHJp YnV0ZSBpbiBhbiBhbnN3ZXIpDQo+DQo+VGhpcyBpcyBhYm91dCB3aGF0IHRvIGRvIGlmIHlvdSBp bmNsdWRlIGE9aWRlbnRpdHkgbm90IGFib3V0IHdoZXRoZXIgdG8NCj5pbmNsdWRlIGl0Lg0KDQpX aGVuIG5ldyBTRFAgYXR0cmlidXRlcyBhcmUgZGVmaW5lZCwgdGhlcmUgbmVlZHMgdG8gYmUgb2Zm ZXIvYW5zd2VyDQpwcm9jZWR1cmVzLiBCZWNhdXNlLCBJIGFzc3VtZSB0aGUgYXR0cmlidXRlIGNh biBiZSB1c2VkIG9uIHRoZSB3aXJlLCBpbg0KU0RQIG9mZmVycyBhbmQgYW5zd2Vycz8NCg0KQWxz bywgaWYgdGhlIGF0dHJpYnV0ZSBpcyBzY29wZWQgdG8gV2ViUlRDLCBvciB0byBzb21lIHNwZWNp ZmljIHNlY3VyaXR5DQpzb2x1dGlvbnMsIEkgdGhpbmsgdGhhdCBhbHNvIG5lZWRzIHRvIGJlIGNv dmVyZWQuDQoNCg0KPj4gSG93ZXZlciwgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItc2RwIGl0IGlzIGlu Y2x1ZGVkIGluIGJvdGggdGhlIG9mZmVyIGFuZA0KPj4gYW5zd2VyLg0KPg0KPkkgdGhpbmsgdGhh dCBkcmFmdC1pZXRmLXJ0Y3dlYi1zZHAgaW5jbHVkZXMgdGhlbSBpbiBib3RoIHRoZSBvZmZlciBh bmQNCj50aGUgYW5zd2VyIGJlY2F1c2UgdGhlIGV4YW1wbGVzIGFyZSB1c2luZyB0aGUgV0VCUlRD IElkZW50aXR5IG1lY2hhbmlzbS4NCj5JIHRoaW5rIHRoaXMgaXMgY29uc2lzdGVudCB3aXRoIHdo YXQgaXMgaW4gYm90aCBkcmFmdC1pZXRmLXJ0Y3dlYi1zZHAgYW5kDQo+ZHJhZnQtaWV0Zi1ydGN3 ZWItanNlcDoNCj4NCj4gICBJZiBXZWJSVEMgaWRlbnRpdHkgaXMgYmVpbmcgdXNlZCwgYW4gImE9 aWRlbnRpdHkiIGxpbmUgYXMNCj4gICBkZXNjcmliZWQgaW4gW0ktRC5pZXRmLXJ0Y3dlYi1zZWN1 cml0eS1hcmNoXSwgU2VjdGlvbiA1Lg0KDQoNClRoYXQgc2VudGVuY2UgaXMgb25seSBmb3IgdGhl IGluaXRpYWwgb2ZmZXIuIFVubGVzcyBJoa92ZSBtaXNzZWQgaXQsIHRoZXJlDQppcyBubyB0ZXh0 IGFib3V0IGE9aWRlbnRpdHkgcmVnYXJkaW5nIGFuc3dlcnMuDQoNCg0KPj4gUTI6DQo+PiAtLS0N Cj4+IA0KPj4gQWxzbywgdGhlIG11eCBjYXRlZ29yeSBpcyBtaXNzaW5nIChkcmFmdC1pZXRmLW1t dXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMNCj4+IGFsc28gY292ZXJzIHNlc3Npb24tbGV2ZWwgYXR0 cmlidXRlcykuIEkgYXNzdW1lIGl0IGlzIKn4Tk9STUFMqfcuDQo+DQo+SSB0aGluayB0aGlzIG1h bnMgYWRkaW5nOg0KPg0KPiAgTXV4IENhdGVnb3J5OiBOT1JNQUwNCj4NCj50byB0aGUgSUFOQSBy ZWdpc3RyYXRpb24/DQoNCkNvcnJlY3QuIEJ1dCwgTk9STUFMIGlzIGp1c3QgbXkgYXNzdW1wdGlv biAtICBJIHdhbnQgcGVvcGxlIHRvIGNvbmZpcm0NCndoZXRoZXIgdGhhdCBpcyBjb3JyZWN0IDop DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KPj4gUmVnYXJkcywNCj4+IA0KPj4gQ2hyaXN0 ZXINCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gT24gMjMvMDQvMTggMDE6 NDcsICJydGN3ZWIgb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uIg0KPj4gPHJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+IHdyb3Rl Og0KPj4gDQo+Pj4gdGxzLWlkIGlzIGNvbm5lY3Rpb24tYmFzZWQgKGkuZS4sIGl0IGFwcGxpZXMg dG8gYSBzaW5nbGUgYnVuZGxlKSwNCj4+PiB3aGVyZWFzIGlkZW50aXR5IGlzIHNlc3Npb24tYmFz ZWQuICBUaGF0IHdhcyBteSBpbml0aWFsIHRob3VnaHQsIGJ1dA0KPj4+IHRoZW4gd2UgaGF2ZSB0 byBkZWFsIHdpdGggdGhlIDE6TiBwcm9ibGVtIHRoZXJlLiAgVGhlIHNpbXBsZXN0DQo+Pj4gYXBw cm9hY2ggbWlnaHQgYmUgdG8gbW92ZSBhPWlkZW50aXR5IHRvIHRoZSBidW5kbGUsIGJ1dCB0aGF0 IGxlYWRzIHRvDQo+Pj4gc29tZSBpbnRlcmVzdGluZyBkb3duc3RyZWFtIGVmZmVjdHMuICBZb3Ug cHJvYmFibHkgd2FudCB0byBhdm9pZA0KPj4+IGhhdmluZyBtdWx0aXBsZSBpZGVudGl0aWVzIGlu IHRoZSBzYW1lIFJUQ1BlZXJDb25uZWN0aW9uLCBmb3INCj4+PiBpbnN0YW5jZS4NCj4+PiANCj4+ PiBPbiBTYXQsIEFwciAyMSwgMjAxOCBhdCAxMToxMCBBTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0 Zm0uY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPbiBUaHUsIEFwciAxMiwgMjAxOCBh dCA2OjQ1IEFNLCBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+ Pj4+PiBUaGUgV0dMQyBmb3IgdGhpcyBkb2N1bWVudCBoYXMgZW5kZWQuICBJIHRoaW5rIGl0IHdh cyByZWFsbHkgZ29vZA0KPj4+Pj50aGF0DQo+Pj4+PiBADQo+Pj4+PiBJRVRGMTAxIHRoZSBJZFAg aGFja2F0aG9uIGhhcHBlbmVkIGJlY2F1c2UgaXQgbG9va2VkIGxpa2UgdGhleSBtaWdodA0KPj4+ Pj4gaGF2ZQ0KPj4+Pj4gdW5jb3ZlcmVkIHNvbWV0aGluZyB0byBiZSBjaGFuZ2VkIGluIG91ciBk b2N1bWVudCBhbmQgcG9zc2libHkgaW4gdGhlDQo+Pj4+PiB3ZWJydGMtcGMgZHJhZnQ7IHNlZSB0 aGUgWzBdIHRocmVhZC4gIEFzIHRoZSBTaGVwaGVyZCB0cnlpbmcgdG8gZHJpdmUNCj4+Pj4+IHRo aXMNCj4+Pj4+IHRvIGNsb3N1cmUsIHdlIG5lZWQgdG8gd2UgbmVlZCB0byBkZWNpZGUgd2hhdCBj aGFuZ2VzIG1pZ2h0IGJlIG1hZGUNCj4+Pj4+aW4NCj4+Pj4+IGRyYWZ0LWlldGYtcnRjd2ViLXNl Y3VyaXR5LWFyY2guICBJbiB0aGF0IHRocmVhZCwgSSBzYXcgdHdvIHRoaW5ncw0KPj4+Pj4gdGhh dCB3ZQ0KPj4+Pj4gbWlnaHQgY2hhbmdlIChib3RoIGZyb20gbXQpOg0KPj4+Pj4gDQo+Pj4+PiAw KSBNb3JlIHRleHQgdG8gYWRkcmVzcyBhIGxpbmthYmlsaXR5IGNvbmNlcm46DQo+Pj4+PiANCj4+ Pj4+ICBBcyBhIHByYWN0aWNhbCBtYXR0ZXIsIGlmIHRoZSBicm93c2VyIHdlcmUgdG8gdXNlIHRo ZSBzYW1lDQo+Pj4+PiBjZXJ0aWZpY2F0ZQ0KPj4+Pj4gIGZvciBtdWx0aXBsZSBvcmlnaW5zLCB0 aGVuIGl0IHdvdWxkIGNyZWF0ZSBhIG1hc3NpdmUgcHJpdmFjeSBwcm9ibGVtDQo+Pj4+PiAgdGhh dCBlbmFibGVzIGxpbmthYmlsaXR5IChha2EgdXNlciB0cmFja2luZykuICBJIGNvdWxkbid0IGZp bmQgdGhhdA0KPj4+Pj4gIHdyaXR0ZW4gZG93biwgYnV0IEkgdGhvdWdodCBpdCB3YXMuICBJZiBp dCBpc24ndCB3cml0dGVuIGRvd24sIHRoZW4NCj4+Pj4+IHdlDQo+Pj4+PiAgc2hvdWxkIGNvcnJl Y3QgdGhhdC4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBJc24ndCB0aGlzIHRoZSByZWxldmFudCB0ZXh0 Og0KPj4+PiAiDQo+Pj4+IA0KPj4+PiAgIEFQSSBSZXF1aXJlbWVudDogIFVubGVzcyB0aGUgdXNl ciBzcGVjaWZpY2FsbHkgY29uZmlndXJlcyBhbg0KPj4+PmV4dGVybmFsDQo+Pj4+ICAgICAga2V5 IHBhaXIsIGRpZmZlcmVudCBrZXkgcGFpcnMgTVVTVCBiZSB1c2VkIGZvciBlYWNoIG9yaWdpbi4N Cj4+Pj4oVGhpcw0KPj4+PiAgICAgIGF2b2lkcyBjcmVhdGluZyBhIHN1cGVyLWNvb2tpZS4pDQo+ Pj4+IA0KPj4+PiAiDQo+Pj4+IA0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4gSSBhY3R1YWxseSB0aGlu ayB0aGlzIGlzIGJhc2ljYWxseSBjb3ZlcmVkIGhlcmU6DQo+Pj4+PiANCj4+Pj4+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LTEwI3NlY3Rpb24t NC40Lg0KPj4+Pj4xDQo+Pj4+PiBCdXQgd2FudCB0byBtYWtlIHN1cmUgb3RoZXJzIGFncmVlOg0K Pj4+Pj4gDQo+Pj4+PiAxKSBUd2VhayBwcm90b2NvbCB0byBpbmNsdWRlIGFuIGlkZW50aWZpZXIg dG8gcHJldmVudCByZXVzZSBvZg0KPj4+Pj4gYXNzZXJ0aW9uDQo+Pj4+PiBvbiBldmVyeSBSVENQ ZWVyQ29ubmVjdGlvbjoNCj4+Pj4+IA0KPj4+Pj4gIE1vcmUgY29tcGxleCBzaXRlcyBmcmVxdWVu dGx5IGdlbmVyYXRlIG11bHRpcGxlIFJUQ1BlZXJDb25uZWN0aW9uDQo+Pj4+PiAgaW5zdGFuY2Vz IGZvciB0aGVpciBjb21tdW5pY2F0aW9ucywgZXNwZWNpYWxseSBmb3IgZ3JvdXANCj4+Pj4+ICBj b252ZXJzYXRpb25zLiAgSWYgdGhlIGJyb3dzZXIgcmVxdWVzdHMgYW4gYXNzZXJ0aW9uIG9uY2Ug YW5kIHRoZXkNCj4+Pj4+IHVzZQ0KPj4+Pj4gIHRoYXQgdmFsdWUgZm9yIGV2ZXJ5IFJUQ1BlZXJD b25uZWN0aW9uLCB0aGVuIHRoYXQncyBPSy4gIEZyb20gbXkNCj4+Pj4+ICBwZXJzcGVjdGl2ZSwg SSB3b3VsZCBiZSBoYXBweSBtb2RpZnlpbmcgdGhlIHByb3RvY29sIHRvIGluY2x1ZGUgYW4NCj4+ Pj4+ICBpZGVudGlmaWVyIGFuZCBwcmV2ZW50IHRoYXQ7IGZvciB0aGlzIHRoZSBJZFAgY2FuIHVz ZSBjYWNoaW5nIG9yIGl0cw0KPj4+Pj4gIGxvY2FsIHN0b3JhZ2UuDQo+Pj4+PiANCj4+Pj4+IFNv LCB3aGF0IHdvdWxkIHRoYXQgbG9vayBsaWtlPw0KPj4+PiANCj4+Pj4gDQo+Pj4+IFdvdWxkbid0 IGl0IGJlIHN1ZmZpY2llbnQgdG8gaW5jbHVkZSB0aGUgdGxzLWlkIGluIHRoZSBpZGVudGl0eQ0K Pj4+PmJpbmRpbmc/DQo+Pj4+IA0KPj4+PiAtRWtyDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+ Pj4+IA0KPj4+Pj4gRGlkIEkgbWlzcyBhbnl0aGluZyBlbHNlIHRoYXQgbmVlZHMgdG8gYmUgYWRk cmVzc2VkPw0KPj4+Pj4gDQo+Pj4+PiBzcHQNCj4+Pj4+IA0KPj4+Pj4gWzBdDQo+Pj4+PiANCj4+ Pj4+IA0KPj4+Pj5odHRwczovL21haWxhcmNoaXZlLmlldGYuLm9yZy9hcmNoL21zZy9ydGN3ZWIv MnIydTIwVVFJS3dOZVkxUHNZRnJEdzdqDQo+Pj4+PlhFDQo+Pj4+PiB3DQo+Pj4+PiANCj4+Pj4+ PiBPbiBNYXIgMTIsIDIwMTgsIGF0IDE5OjA4LCBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+ IHdyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+IEFsbCwNCj4+Pj4+PiANCj4+Pj4+PiBUaGlzIGlzIHRo ZSBXR0xDIGZvciB0aGUgqfhXZWJSVEMgU2VjdXJpdHkgQXJjaGl0ZWN0dXJlqfcgZHJhZnQNCj4+ Pj4+IGF2YWlsYWJsZQ0KPj4+Pj4+IEAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHkvLg0KPj4+Pj4gUGxlYXNlDQo+Pj4+Pj4gcmV2aWV3 IHRoZSBkcmFmdCBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoaXMgbGlzdCBieSAyMzU5VVRD IG9uDQo+Pj4+PiBBcHJpbA0KPj4+Pj4+IDZ0aCwgMjAxOC4NCj4+Pj4+PiANCj4+Pj4+PiBOb3Rl IHRoZSBnaCByZXBvIGlzIGhlcmU6DQo+Pj4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13 Zy9zZWN1cml0eS1hcmNoDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+IEMvVC9TDQo+ Pj4+PiANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+Pj4+IA0K Pj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+Pj4gcnRjd2ViQGlldGYub3Jn DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+Pj4+ IA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+PiANCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBydGN3ZWIgbWFp bGluZyBsaXN0DQo+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+DQoNCg== From nobody Fri Apr 27 11:22:29 2018 Return-Path: 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 5E2D4124205 for ; Fri, 27 Apr 2018 11:22:28 -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=unavailable 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 m-G_u2EM5JLL for ; Fri, 27 Apr 2018 11:22:26 -0700 (PDT) Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (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 0FEEE127AD4 for ; Fri, 27 Apr 2018 11:22:26 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B0861542E; Fri, 27 Apr 2018 14:22:17 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5144E5733; Fri, 27 Apr 2018 14:22:17 -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:587 (trex/5.7.12); Fri, 27 Apr 2018 14:22:17 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_548A517E-C246-405D-BE62-F52F4D04EB9F" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Fri, 27 Apr 2018 12:22:15 -0600 Cc: Nils Ohlmeier , RTCWeb IETF Message-Id: References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> To: Justin Uberti X-Mailer: Apple Mail (2.3445.6.18) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 18:22:28 -0000 --Apple-Mail=_548A517E-C246-405D-BE62-F52F4D04EB9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 17, 2018, at 3:15 AM, Justin Uberti = wrote: >=20 > IMO "trusting the TURN relay but not the application" is not a = significant enough benefit to merit adding specific functionality for. >=20 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.=20 --Apple-Mail=_548A517E-C246-405D-BE62-F52F4D04EB9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 17, 2018, at 3:15 AM, Justin Uberti <juberti=3D40google.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. 


= --Apple-Mail=_548A517E-C246-405D-BE62-F52F4D04EB9F-- From nobody Fri Apr 27 17:13:16 2018 Return-Path: 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 A59FC12AAB6 for ; Fri, 27 Apr 2018 17:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com 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 Pk8_Xp13hrHx for ; Fri, 27 Apr 2018 17:13:11 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.207]) (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 5950A126CBF for ; Fri, 27 Apr 2018 17:13:11 -0700 (PDT) Received: from [216.82.242.36] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-15.bemta-8.messagelabs.com id EE/8D-22406-69CB3EA5; Sat, 28 Apr 2018 00:13:10 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA2WTa0wTWRTHe2am00GoDgXk2PgIje5KtRWiRFz XIOuLqJuw7oYPBaNTHWljW6BTDMYPghp5GRcNGEoCiDaSoF2FyPok0kaFIpGIhiiiwaAfEBWJ xFcQnOlUdzf75eZ3z/9/HvfOHYbUHFNpGb7AxTsdnE1HT6N6jKeTDFXXh0wJ452JyW/Pf4Rk7 2SxKvlBUxG5mkzzeD4Rafd7xiDN54N00qS0Osw5BduVlqttVyF3vBoKqk8XU4XQWgZlMI2h2F ECn95wE9JGw1YR2NFaGNoMAnp6C8kyCGNoNgH72joIiaPZVGwabackJtk4HG+sp6WEKLYEsPN db8hUCthRtF7mn7BhalAlMcUuQG9LXZDVbBY2vz+klLvVAo6876clIUxMGO1rDpqAnYkfus4R crdY7H9eH2Rko/HZvTu0zDE4PDSplP1ZWPvOH4rr8K9XAyH/HOytLw8eGtmLBF7v9illwYBvq 6pImdsB3VPzZdbj68CfoocReTee7cmQw5nY8vFmqI6HRF9pgJKF2dh+uF8lC3/T6C0tChbVsD uxsslPy8IQ4JcGb7BzFKvFJw9KoQL0Nf86XY3oI9l6wID3KV0TvKdIDLifU7LJhGUd5SqZ9eg 5MBXiRXimYYSUOR7HKx5T/4+vxOrPProm9OEqy5+FcpNw5NYYnITwJlgo8M49vNOwLMlodlqz LS47Z7UZEhOSjXZeELhs3saZBeOOHHsLiI9xv0IBl2HyZqYfZjGELkY9b9OQSTPdnLNzr4UTL Nuc+TZe8MNshtGheoH4aDWRTj6bL9hltYkv+puMTIQuWm2QZLWQy9kFa7YsdUEKM3Dx+BGSKR mtFFd/cL0rrRrKkePgtbHqVCmNldIs+Y7vRb/9Kb0wRxulBoVCoYnI5Z12q+u/+kuIZUAXpd4 sVYmwOlzfe78UxyLEsbjIQWksF/ePpC2EH0sudbnzBxTGiXi9tXnL4WsxVN1Sc8b83/N8R3/7 JXWi+MTDvq2PPqx9FdcW251Cbti3PCPw84w34Sds+nPGaNMPG7fXtu6rXUPHMe11f3SnH1x4Z l7W+U6mMe3KigvDmROrqJQ19xb/GjZyJ/1246G84bxj68buu+e+iB8IX1Jxqu9gsY4SLFyinn QK3FfBf/goJAQAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-11.tower-94.messagelabs.com!1524874388!194562937!1 X-Originating-IP: [207.46.163.53] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 83672 invoked from network); 28 Apr 2018 00:13:09 -0000 Received: from mail-cys01nam02lp0053.outbound.protection.outlook.com (HELO NAM02-CY1-obe.outbound.protection.outlook.com) (207.46.163.53) by server-11.tower-94.messagelabs.com with AES256-SHA256 encrypted SMTP; 28 Apr 2018 00:13:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PnUT2RZsVzpaJ7tKp7SfoNcUhiZrHeNyKkUv3O8POOs=; b=nZ1EfYXctkopC+j4wIUHqQ2oDpXUiqbYqm259i6CMA5mK9fMuht6txzOs2kpFTn+60W9DAKM+XE6vfYQ8gdfgaQdyBp7xD0HSAjFlyEe8HCUJsg3llSAut6YmCCuTMrMFmNpcZy+b0AYBqe9NTRnJUQV3F3wb26zx15fiH9wpZM= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1359.namprd14.prod.outlook.com (10.173.232.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Sat, 28 Apr 2018 00:13:06 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::c033:7973:d34d:e13f]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::c033:7973:d34d:e13f%17]) with mapi id 15.20.0715.018; Sat, 28 Apr 2018 00:13:06 +0000 From: Tim Hollebeek To: Cullen Jennings , Sean Turner CC: RTCWeb IETF Thread-Topic: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) Thread-Index: AQHT0mSHdSosj9h75EqZv/oIt1x5RqQT4huAgAGAhZA= Date: Sat, 28 Apr 2018 00:13:06 +0000 Message-ID: References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> In-Reply-To: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1359; 7:+gb9FCZ0Tu84rhXR3xFfbwtxAIYFjfeZOa4ZmdM616wUzQDquTV+NQCHFyIWfSCvLrfu45peme0p/XJnLR8Xm4Ilo3XIfEEJZ/TDmMuFqwKuSNIX5DFBRBeAcq8ZTKlUJ0tokMPEmxcJdP9Cg1Og6IdiB8VW014RPrb+/66BqsEK6kaIzAJAp22NGk3GSyK3CC0LnUntKiTSdVbgTBqYDrmsLmT0pDVI7lBIy6fb53QU7ZKA7tZF+nR84dqL8BLw x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1359; x-ms-traffictypediagnostic: MWHPR14MB1359: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231243)(944501410)(52105095)(3002001)(93006095)(93001095)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR14MB1359; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1359; x-forefront-prvs: 0656A4403B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(39380400002)(396003)(39860400002)(199004)(189003)(7110500001)(105586002)(44832011)(8676002)(7736002)(6116002)(3846002)(33656002)(66066001)(6436002)(99936001)(11346002)(102836004)(8936002)(26005)(53546011)(790700001)(6506007)(68736007)(486006)(3660700001)(7696005)(76176011)(81156014)(81166006)(446003)(25786009)(2900100001)(59450400001)(5250100002)(476003)(316002)(186003)(53936002)(2906002)(86362001)(6246003)(54896002)(5660300001)(236005)(3280700002)(74316002)(97736004)(10710500007)(2420400007)(99286004)(4326008)(15650500001)(478600001)(110136005)(9686003)(55016002)(6306002)(14454004)(229853002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1359; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: P0NcqT0+xt6Yqe9oIyeAJCGSgc9Sg4qX+DTkCD4ot8zIGO2YrGCVg5xbjqawXiIjYPi2n+6oniwCFVT5jliF4K48PEXdPC8GEijveUHAZXorgDa/nZx9DIUDDNMxZbPy2G6y7PnGIRbbo5vNKwILMN6YXXTHesMors+kH37AwipHKBEbrpIh0YzCJkKD0QWN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0152_01D3DE64.248F18D0" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 6d20083b-8a64-483f-c3ab-08d5ac9cd10e X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d20083b-8a64-483f-c3ab-08d5ac9cd10e X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2018 00:13:06.4137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1359 Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 00:13:15 -0000 ------=_NextPart_000_0152_01D3DE64.248F18D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0153_01D3DE64.248F18D0" ------=_NextPart_001_0153_01D3DE64.248F18D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m going from my memory from the IETF 101 hackathon here, so = someone feel free to correct me if I=E2=80=99m remembering the details = wrong (I probably am for at least some of it), but as I recall it, the = issue was essentially that when one requests an identity assertion, if = one presents it to someone, the security properties are Awesome [TM] = because only authorized persons can get an identity assertion from the = IDP. =20 However, after one has presented an identity assertion to a potentially = untrusted party, presentation of that assertion to additional parties is = Slightly Less Than Awesome [TM], because the additional parties cannot = distinguish between the person who legitimately obtained the identity = assertion, and the party to which the identity assertion was previously = presented. =20 Various arguments were made that this is not a problem because the = lifetime of identity assertions is short, with lifetimes on the order of = days to hours. There was also some discussion (before the issue was = found) about if expiration of the relevant temporary certificates needed = to be checked at all. Call me crazy, but only having a few hours to = carry out my attack doesn=E2=80=99t hinder me much as an attacker! =20 One solution that was discussed, which may or may not work for all use = cases and this certainly should be explored, was that identity = assertions are cheap and therefore supporting the complexity of identity = assertion re-use might not make sense. We discussed simply adding a = nonce to the creation of identity assertions, so IDPs could enforce that = they are validated only once, essentially turning them into bearer = tokens. If the process fails (network hiccup, etc) it is possible to = transparently regenerate a new assertion and retry. IIRC certain = non-attack failure scenarios needed this retry logic anyway. =20 If needed, I can go back and re-read the messages from that weekend to = help refresh my memory, but that=E2=80=99s what I remember. =20 -Tim =20 From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen = Jennings Sent: Thursday, April 26, 2018 9:03 PM To: Sean Turner Cc: RTCWeb IETF Subject: Re: [rtcweb] Addressing WGLC comments for = draft-ietf-rtcweb-security-arch? (was Re: WGLC for = draft-ietf-rtcweb-security-arch) =20 =20 On Apr 12, 2018, at 7:45 AM, Sean Turner > wrote: =20 1) Tweak protocol to include an identifier to prevent reuse of assertion = on every RTCPeerConnection: More complex sites frequently generate multiple RTCPeerConnection instances for their communications, especially for group conversations. If the browser requests an assertion once and they use that value for every RTCPeerConnection, then that's OK. From my perspective, I would be happy modifying the protocol to include an identifier and prevent that; for this the IdP can use caching or its local storage. So, what would that look like? =20 It=E2=80=99s not clear to me what the problem we are solving here is. = Who are we trying to stop from reusing an assertion and why. The = assertion is already bound to the specific private key and specific web = origin. The IdP can bind it to a narrow time range if the IdP wants ( = most do). I=E2=80=99m not seeing the big difference from reusing an = assertion vs. asking the for a bunch of them. The protocol that users = the assertion may end up forking the same assertion to many places = regardless of what the browser does.=20 =20 Changing this so that the IdP see how many PeerConnections are formed = seems like it just reveal more usage information to the IdP and does not = help security. =20 Assuming I am just not getting the problem and we do want to solve this = =E2=80=A6 I is not clear to me how to make this all work with tls-id due = to all the bundle issues. Another approach would the browser greater a = GUID for the PeerConnection and that is passed in the IdP proxy code and = the IdP can bind it into the assertion or not but if it does bind into = the assertion, then the browser will only validate the assertion on the = PeerConnection with matching GUID. This is probably wrong and half baked = as I don=E2=80=99t really get the problem.=20 =20 =20 ------=_NextPart_001_0153_01D3DE64.248F18D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I=E2=80=99m going from my memory from the IETF 101 = hackathon here, so someone feel free to correct me if I=E2=80=99m = remembering the details wrong (I probably am for at least some of it), = but as I recall it, the issue was essentially that when one requests an = identity assertion, if one presents it to someone, the security = properties are Awesome [TM] because only authorized persons can get an = identity assertion from the IDP.

 

However, = after one has presented an identity assertion to a potentially untrusted = party, presentation of that assertion to additional parties is Slightly = Less Than Awesome [TM], because the additional parties cannot = distinguish between the person who legitimately obtained the identity = assertion, and the party to which the identity assertion was previously = presented.

 

Various arguments were made that this is not a problem = because the lifetime of identity assertions is short, with lifetimes on = the order of days to hours.=C2=A0 There was also some discussion (before = the issue was found) about if expiration of the relevant temporary = certificates needed to be checked at all.=C2=A0 Call me crazy, but only = having a few hours to carry out my attack doesn=E2=80=99t hinder me much = as an attacker!

 

One solution = that was discussed, which may or may not work for all use cases and this = certainly should be explored, was that identity assertions are cheap and = therefore supporting the complexity of identity assertion re-use might = not make sense. =C2=A0We discussed simply adding a nonce to the creation = of identity assertions, so IDPs could enforce that they are validated = only once, essentially turning them into bearer tokens.=C2=A0 If the = process fails (network hiccup, etc) it is possible to transparently = regenerate a new assertion and retry.=C2=A0 IIRC certain non-attack = failure scenarios needed this retry logic anyway.

 

If needed, I = can go back and re-read the messages from that weekend to help refresh = my memory, but that=E2=80=99s what I remember.

 

-Tim

 

From: = rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen = Jennings
Sent: Thursday, April 26, 2018 9:03 PM
To: = Sean Turner <sean@sn3rd.com>
Cc: RTCWeb IETF = <rtcweb@ietf.org>
Subject: Re: [rtcweb] Addressing WGLC = comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for = draft-ietf-rtcweb-security-arch)

 

 



On Apr 12, 2018, at 7:45 AM, Sean Turner <sean@sn3rd.com> = wrote:

 

1) Tweak = protocol to include an identifier to prevent reuse of assertion on every = RTCPeerConnection:

 More complex sites frequently generate = multiple RTCPeerConnection
 instances for their communications, = especially for group
 conversations.  If the browser = requests an assertion once and they use
 that value for every = RTCPeerConnection, then that's OK.  From my
 perspective, I = would be happy modifying the protocol to include an
 identifier = and prevent that; for this the IdP can use caching or its
 local = storage.

So, what would that look = like?

 

It=E2=80=99s not clear to me what the problem we are = solving here is. Who are we trying to stop from reusing an assertion and = why. The assertion is already bound to the specific private key and = specific web origin. The IdP can bind it to a narrow time range if the = IdP wants ( most do). I=E2=80=99m not seeing the big difference from = reusing an assertion vs. asking the for a bunch of them. The protocol = that users the assertion may end up forking the same assertion to many = places regardless of what the browser = does. 

 

Changing this so that the IdP see how many = PeerConnections are formed seems like it just reveal more usage = information to the IdP and does not help = security.

 

Assuming I am just not getting the problem and we do = want to solve this =E2=80=A6 I is not clear to me how to make this all = work with tls-id due to all the bundle issues. Another approach would = the browser greater a GUID for the PeerConnection and that is passed in = the IdP proxy code and the IdP can bind it into the assertion or not but = if it does bind into the assertion, then the browser will only validate = the assertion on the PeerConnection with matching GUID. This is probably = wrong and half baked as I don=E2=80=99t really get the = problem. 

 

 

------=_NextPart_001_0153_01D3DE64.248F18D0-- ------=_NextPart_000_0152_01D3DE64.248F18D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNDI4MDAxMzAxWjAvBgkqhkiG9w0BCQQxIgQg1Ax6xYG0WM84IatzX8lyBq5XgObE Jj01wGFCV3XBNbgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAEsWcDmOqA4FusoQhiRBYRyHLaGDVQNLldTbr1jqJiwhZCjkx0reV4Y8V1so5z+9g6+gwPIx Hu7iq9uw/dGxzQeeqXUOvgbP9TDoVXxh/bBwZQ9QBQc0udTsmKzJY5X4Zr75R7WQJULVouoSAySn VOICmnFGbh6KmHK7MXez4r6FEaUrZ0B8pJLu8ohFG6uQDZaNxgUIERY2y7B62n2iSoickCPO4Zlt grZg0SEwnoyTmT2WegPIWc+8/ViK3I3lcfzf0sAe7p/Z5FVRZ+QA7j3VT2y6ifwz0E0NCmo/TY2x kxheckLt+SV+2LG4YuOU4+J9lGAIq6co1QAeYv6+O2EAAAAAAAA= ------=_NextPart_000_0152_01D3DE64.248F18D0-- From nobody Sat Apr 28 09:01:32 2018 Return-Path: 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 3C8D5126CC4 for ; Sat, 28 Apr 2018 09:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gP_mKYiq1tqF for ; Sat, 28 Apr 2018 09:01:28 -0700 (PDT) Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (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 7000C126C25 for ; Sat, 28 Apr 2018 09:01:28 -0700 (PDT) Received: from smtp2.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0C85B58DF; Sat, 28 Apr 2018 12:01:20 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp2.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6155B441F; Sat, 28 Apr 2018 12:01:19 -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:587 (trex/5.7.12); Sat, 28 Apr 2018 12:01:20 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_5010273F-739B-404E-859E-422C6C369CF2" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Sat, 28 Apr 2018 10:01:17 -0600 Cc: Sean Turner , RTCWeb IETF Message-Id: <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> To: Tim Hollebeek X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 16:01:31 -0000 --Apple-Mail=_5010273F-739B-404E-859E-422C6C369CF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tim - that sounds about right but this is the part I don=E2=80=99t = get=E2=80=A6.=20 All the identity assertion does is bind the public key from the TLS = connection to the a name/identity. Think of it like a certificate that = binds my private key to name. Anyone can get my cert and pass it around = however they want. That is fine. Similarly the assertion can be passed = around handed to bad people etc. But anyone using it need to match it = with a TLS connection that does proof of possession of the private key = that matches the public key. That private key is going to be very = narrowly scoped on what has access to it. People that want to rely on = this identity assertion have to be sure that they require proof of = possession of private key. So I do not see the issue at all that the identity assertion, just like = a normal X508 certificate, can be passed around. I=E2=80=99m not getting = whey this is Slightly Less than Awesome :-)=20 I=E2=80=99m not arguing there is no problem, but I am not getting what = the problem is.=20 Cullen=20 > On Apr 27, 2018, at 6:13 PM, Tim Hollebeek = wrote: >=20 > I=E2=80=99m going from my memory from the IETF 101 hackathon here, so = someone feel free to correct me if I=E2=80=99m remembering the details = wrong (I probably am for at least some of it), but as I recall it, the = issue was essentially that when one requests an identity assertion, if = one presents it to someone, the security properties are Awesome [TM] = because only authorized persons can get an identity assertion from the = IDP. > =20 > However, after one has presented an identity assertion to a = potentially untrusted party, presentation of that assertion to = additional parties is Slightly Less Than Awesome [TM], because the = additional parties cannot distinguish between the person who = legitimately obtained the identity assertion, and the party to which the = identity assertion was previously presented. > =20 > Various arguments were made that this is not a problem because the = lifetime of identity assertions is short, with lifetimes on the order of = days to hours. There was also some discussion (before the issue was = found) about if expiration of the relevant temporary certificates needed = to be checked at all. Call me crazy, but only having a few hours to = carry out my attack doesn=E2=80=99t hinder me much as an attacker! > =20 > One solution that was discussed, which may or may not work for all use = cases and this certainly should be explored, was that identity = assertions are cheap and therefore supporting the complexity of identity = assertion re-use might not make sense. We discussed simply adding a = nonce to the creation of identity assertions, so IDPs could enforce that = they are validated only once, essentially turning them into bearer = tokens. If the process fails (network hiccup, etc) it is possible to = transparently regenerate a new assertion and retry. IIRC certain = non-attack failure scenarios needed this retry logic anyway. > =20 > If needed, I can go back and re-read the messages from that weekend to = help refresh my memory, but that=E2=80=99s what I remember. > =20 > -Tim > =20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen = Jennings > Sent: Thursday, April 26, 2018 9:03 PM > To: Sean Turner > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Addressing WGLC comments for = draft-ietf-rtcweb-security-arch? (was Re: WGLC for = draft-ietf-rtcweb-security-arch) > =20 > =20 >=20 >=20 > On Apr 12, 2018, at 7:45 AM, Sean Turner > wrote: > =20 > 1) Tweak protocol to include an identifier to prevent reuse of = assertion on every RTCPeerConnection: >=20 > More complex sites frequently generate multiple RTCPeerConnection > instances for their communications, especially for group > conversations. If the browser requests an assertion once and they = use > that value for every RTCPeerConnection, then that's OK. =46rom my > perspective, I would be happy modifying the protocol to include an > identifier and prevent that; for this the IdP can use caching or its > local storage. >=20 > So, what would that look like? > =20 > It=E2=80=99s not clear to me what the problem we are solving here is. = Who are we trying to stop from reusing an assertion and why. The = assertion is already bound to the specific private key and specific web = origin. The IdP can bind it to a narrow time range if the IdP wants ( = most do). I=E2=80=99m not seeing the big difference from reusing an = assertion vs. asking the for a bunch of them. The protocol that users = the assertion may end up forking the same assertion to many places = regardless of what the browser does.=20 > =20 > Changing this so that the IdP see how many PeerConnections are formed = seems like it just reveal more usage information to the IdP and does not = help security. > =20 > Assuming I am just not getting the problem and we do want to solve = this =E2=80=A6 I is not clear to me how to make this all work with = tls-id due to all the bundle issues. Another approach would the browser = greater a GUID for the PeerConnection and that is passed in the IdP = proxy code and the IdP can bind it into the assertion or not but if it = does bind into the assertion, then the browser will only validate the = assertion on the PeerConnection with matching GUID. This is probably = wrong and half baked as I don=E2=80=99t really get the problem.=20 --Apple-Mail=_5010273F-739B-404E-859E-422C6C369CF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Tim - that sounds about right but this = is the part I don=E2=80=99t get=E2=80=A6. 

All the identity assertion does is bind = the public key from the TLS connection to the a name/identity. Think of = it like a certificate that binds my private key to name. Anyone can get = my cert and pass it around however they want. That is fine. Similarly = the assertion can be passed around handed to bad people etc. But anyone = using it need to match it with a TLS connection that does proof of = possession of the private key that matches the public key. That private = key is going to be very narrowly scoped on what has access to it. People = that want to rely on this identity assertion have to be sure that they = require proof of possession of private key.

So I do not see the issue at all that = the identity assertion, just like a normal X508 certificate, can be = passed around. I=E2=80=99m not getting whey this is Slightly Less than = Awesome :-) 

I=E2=80=99m not arguing there is no problem, but I am not = getting what the problem is. 

Cullen 



On Apr = 27, 2018, at 6:13 PM, Tim Hollebeek <tim.hollebeek@digicert.com> wrote:

I=E2=80=99m= going from my memory from the IETF 101 hackathon here, so someone feel = free to correct me if I=E2=80=99m remembering the details wrong (I = probably am for at least some of it), but as I recall it, the issue was = essentially that when one requests an identity assertion, if one = presents it to someone, the security properties are Awesome [TM] because = only authorized persons can get an identity assertion from the IDP.
 
However, = after one has presented an identity assertion to a potentially untrusted = party, presentation of that assertion to additional parties is Slightly = Less Than Awesome [TM], because the additional parties cannot = distinguish between the person who legitimately obtained the identity = assertion, and the party to which the identity assertion was previously = presented.
 
Various arguments were made that this is not a problem = because the lifetime of identity assertions is short, with lifetimes on = the order of days to hours.  There was also some discussion (before = the issue was found) about if expiration of the relevant temporary = certificates needed to be checked at all.  Call me crazy, but only = having a few hours to carry out my attack doesn=E2=80=99t hinder me much = as an attacker!
 
One solution that was discussed, which may or may not work = for all use cases and this certainly should be explored, was that = identity assertions are cheap and therefore supporting the complexity of = identity assertion re-use might not make sense.  We discussed = simply adding a nonce to the creation of identity assertions, so IDPs = could enforce that they are validated only once, essentially turning = them into bearer tokens.  If the process fails (network hiccup, = etc) it is possible to transparently regenerate a new assertion and = retry.  IIRC certain non-attack failure scenarios needed this retry = logic anyway.
 
If needed, I can go back and re-read the messages from that = weekend to help refresh my memory, but that=E2=80=99s what I = remember.
 
-Tim
 
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Cullen = Jennings
Sent: Thursday, April 26, 2018 = 9:03 PM
To: Sean Turner <sean@sn3rd.com>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Addressing = WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for = draft-ietf-rtcweb-security-arch)
 
 


On Apr 12, 2018, at 7:45 AM, Sean Turner <sean@sn3rd.com> wrote:
 
1) Tweak protocol to include an identifier to = prevent reuse of assertion on every RTCPeerConnection:

 More complex sites frequently generate multiple = RTCPeerConnection
 instances for their = communications, especially for group
 conversations. =  If the browser requests an assertion once and they use
 that value for every RTCPeerConnection, then that's OK. =  =46rom my
 perspective, I would be happy = modifying the protocol to include an
 identifier and = prevent that; for this the IdP can use caching or its
 local storage.

So, what = would that look like?
 
It=E2=80=99s not clear to me what the = problem we are solving here is. Who are we trying to stop from reusing = an assertion and why. The assertion is already bound to the specific = private key and specific web origin. The IdP can bind it to a narrow = time range if the IdP wants ( most do). I=E2=80=99m not seeing the big = difference from reusing an assertion vs. asking the for a bunch of them. = The protocol that users the assertion may end up forking the same = assertion to many places regardless of what the browser does. 
 
Changing this so that the IdP see how = many PeerConnections are formed seems like it just reveal more usage = information to the IdP and does not help security.
 
Assuming I am just not getting the = problem and we do want to solve this =E2=80=A6 I is not clear to me how = to make this all work with tls-id due to all the bundle issues. Another = approach would the browser greater a GUID for the PeerConnection and = that is passed in the IdP proxy code and the IdP can bind it into the = assertion or not but if it does bind into the assertion, then the = browser will only validate the assertion on the PeerConnection with = matching GUID. This is probably wrong and half baked as I don=E2=80=99t = really get the = problem. 

= --Apple-Mail=_5010273F-739B-404E-859E-422C6C369CF2-- From nobody Sat Apr 28 15:44:41 2018 Return-Path: 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 F20D91273E2 for ; Sat, 28 Apr 2018 15:44:39 -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 KpVGtQBC20w2 for ; Sat, 28 Apr 2018 15:44:38 -0700 (PDT) Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (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 7505A126C26 for ; Sat, 28 Apr 2018 15:44:38 -0700 (PDT) Received: from smtp16.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2D4F659F0; Sat, 28 Apr 2018 18:44:35 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id D14CB1704; Sat, 28 Apr 2018 18:44:34 -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:587 (trex/5.7.12); Sat, 28 Apr 2018 18:44:35 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_0E8F2551-1E78-48BB-B7FA-52F6F1AB0894" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> Date: Sat, 28 Apr 2018 16:44:33 -0600 Cc: RTCWeb IETF Message-Id: <614B5FC9-8FBD-4AF8-A4EC-BE98E31F37DD@iii.ca> References: <08aec6ec-62ce-a1e4-7781-06d50f5f66f5@gmail.com> To: Lennart Grahl X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Amount of streams supported for data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 22:44:40 -0000 --Apple-Mail=_0E8F2551-1E78-48BB-B7FA-52F6F1AB0894 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 11, 2018, at 6:08 AM, Lennart Grahl = wrote: >=20 > Is there any reason why it needs to be a SHOULD? Could we make this a = MUST? Yes =E2=80=A6 when the WG was discussing this the thing that came up was = WebRTC devices that are doing IoT stuff often will not have enough = memory to do the state for 65k of them. So I don=E2=80=99t think we = should require 65k data connections for all uses of rtcweb but theses = devices are unlikely to be using the JS API so the question of what to = do there is different.=20 --Apple-Mail=_0E8F2551-1E78-48BB-B7FA-52F6F1AB0894 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 11, 2018, at 6:08 AM, Lennart Grahl <lennart.grahl@gmail.com> wrote:

Is there any reason why it needs = to be a SHOULD? Could we make this a MUST?

Yes =E2=80=A6 when the WG was discussing this = the thing that came up was WebRTC devices that are doing IoT stuff often = will not have enough memory to do the state for 65k of them. So I = don=E2=80=99t think we should require 65k data connections for all uses = of rtcweb but theses devices are unlikely to be using the JS API so the = question of what to do there is different. 

= --Apple-Mail=_0E8F2551-1E78-48BB-B7FA-52F6F1AB0894-- From nobody Sun Apr 29 21:29:47 2018 Return-Path: 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 BCA8E126E01 for ; Sun, 29 Apr 2018 21:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9cM0_hPmSVQq for ; Sun, 29 Apr 2018 21:29:43 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3222A12D872 for ; Sun, 29 Apr 2018 21:29:43 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id l13-v6so8165595otk.9 for ; Sun, 29 Apr 2018 21:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=z64Zb5NwxWDRpHW3bHRNEvsU7m/5frAq+HhcarH3/IA=; b=HAilYX1Uf/gq64VgSCjQD/I7gaP1QEelhhI/b29YZAbIckELTYMxDTZt5VXVw1JRwQ giRKJ7cK5oAOjQQs3DstcBBha7LCUXw5hWjJxUj7N3M81mBUbf2mg9JkLEBToOzfKvpv MD/7Wv5dPWm7OGR4Rb74RS1lGkCjlJ1DRVjKnNI8O+MY0NVeNImCZKlgLF/hzbD/aNk0 h3/3o/5W+UrdO3RWgYzvBTHSDMpI43wFQIYuw8iEfVe4hmPGbEGmnA7MtgOBGtUJBYnv 8CNiFLEdpi9I49On3pxO23Qah3/vmQoxuDz5TVNsRDiiGFqMKhFBMXogWJQHcB0E+tai +SJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=z64Zb5NwxWDRpHW3bHRNEvsU7m/5frAq+HhcarH3/IA=; b=DynmEutVZuNlMm9C+0D/89a6juRT7jXFtPw8tz8hIf8G9kPUL6R2NHz3w7Hub/3Kkm T0oLdGthFV8hSy6yWpFPpEPo4c9ms/F8x/zpl5yh922gq3GNI3Ph9+OkM2DH26UyPvf1 IWIw+W6P3X+zVlCE7ilTcq5P/HuMHzkD29GmXJ++YLRo6OW+lWtOzpbll6Ea9OpL8CQE vdydz+UI1AeZJ+mda93tmvHXBG6DUQuLwqAK9z38AWrHLWtvKnVpkH1fNAsXiIfcdWIL ZpVRWwzZ/Y9BIM1Kh6+qqPAchGaV0EyTp3LG6JqtNgvLT49ohisZydowq56IJSULjU+A f5xg== X-Gm-Message-State: ALQs6tCa8Ohsrnn7rBQobGRX5VNgQxZ0p+KxWjXTROu2fxAXF8RN8wvV kG8BiKm4kb0u/w7H5wsVQXMJywdPRkC/DfZo4hc= X-Google-Smtp-Source: AB8JxZrnpLLZdG0mWPqiAxqb5dr7QxNunGI/w/6T+ozhe+i8MsRq/VSl6Kzk1q8Njt4lvQ8sjgEWtvWfBagpT2/GExo= X-Received: by 2002:a9d:354a:: with SMTP id l10-v6mr1895851ote.15.1525062582453; Sun, 29 Apr 2018 21:29:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:29ce:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 21:29:42 -0700 (PDT) In-Reply-To: <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> From: Martin Thomson Date: Mon, 30 Apr 2018 14:29:42 +1000 Message-ID: To: Cullen Jennings Cc: Tim Hollebeek , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 04:29:46 -0000 I agree with Cullen. I would also point out that with an intended recipient, the IdP can limit the information that can be obtained from an assertion. If the assertion were provided to other than the intended recipient, the IdP could refuse to provide an identity. That requires authenticating the recipient as well, which isn't something we naturally assume, but the mechanisms for enabling that are all in place. FWIW, I think that an abundance of caution suggests that limiting the assertion to a particular session is sensible. The problem there is that we would need a session identifier in order to do that. Until we discovered that RTCCertificate was portable, that was considered sufficient, I would prefer to remove that portability. Maybe we should consider adding an origin to RTCCertificate that would allow it to be moved to other origins, but not be used by them. On Sun, Apr 29, 2018 at 2:01 AM, Cullen Jennings wrote: > > Tim - that sounds about right but this is the part I don=E2=80=99t get=E2= =80=A6. > > All the identity assertion does is bind the public key from the TLS > connection to the a name/identity. Think of it like a certificate that bi= nds > my private key to name. Anyone can get my cert and pass it around however > they want. That is fine. Similarly the assertion can be passed around han= ded > to bad people etc. But anyone using it need to match it with a TLS > connection that does proof of possession of the private key that matches = the > public key. That private key is going to be very narrowly scoped on what = has > access to it. People that want to rely on this identity assertion have to= be > sure that they require proof of possession of private key. > > So I do not see the issue at all that the identity assertion, just like a > normal X508 certificate, can be passed around. I=E2=80=99m not getting wh= ey this is > Slightly Less than Awesome :-) > > I=E2=80=99m not arguing there is no problem, but I am not getting what th= e problem > is. > > Cullen > > > > On Apr 27, 2018, at 6:13 PM, Tim Hollebeek > wrote: > > I=E2=80=99m going from my memory from the IETF 101 hackathon here, so som= eone feel > free to correct me if I=E2=80=99m remembering the details wrong (I probab= ly am for > at least some of it), but as I recall it, the issue was essentially that > when one requests an identity assertion, if one presents it to someone, t= he > security properties are Awesome [TM] because only authorized persons can = get > an identity assertion from the IDP. > > However, after one has presented an identity assertion to a potentially > untrusted party, presentation of that assertion to additional parties is > Slightly Less Than Awesome [TM], because the additional parties cannot > distinguish between the person who legitimately obtained the identity > assertion, and the party to which the identity assertion was previously > presented. > > Various arguments were made that this is not a problem because the lifeti= me > of identity assertions is short, with lifetimes on the order of days to > hours. There was also some discussion (before the issue was found) about= if > expiration of the relevant temporary certificates needed to be checked at > all. Call me crazy, but only having a few hours to carry out my attack > doesn=E2=80=99t hinder me much as an attacker! > > One solution that was discussed, which may or may not work for all use ca= ses > and this certainly should be explored, was that identity assertions are > cheap and therefore supporting the complexity of identity assertion re-us= e > might not make sense. We discussed simply adding a nonce to the creation= of > identity assertions, so IDPs could enforce that they are validated only > once, essentially turning them into bearer tokens. If the process fails > (network hiccup, etc) it is possible to transparently regenerate a new > assertion and retry. IIRC certain non-attack failure scenarios needed th= is > retry logic anyway. > > If needed, I can go back and re-read the messages from that weekend to he= lp > refresh my memory, but that=E2=80=99s what I remember. > > -Tim > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jenning= s > Sent: Thursday, April 26, 2018 9:03 PM > To: Sean Turner > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Addressing WGLC comments for > draft-ietf-rtcweb-security-arch? (was Re: WGLC for > draft-ietf-rtcweb-security-arch) > > > > > On Apr 12, 2018, at 7:45 AM, Sean Turner wrote: > > 1) Tweak protocol to include an identifier to prevent reuse of assertion = on > every RTCPeerConnection: > > More complex sites frequently generate multiple RTCPeerConnection > instances for their communications, especially for group > conversations. If the browser requests an assertion once and they use > that value for every RTCPeerConnection, then that's OK. From my > perspective, I would be happy modifying the protocol to include an > identifier and prevent that; for this the IdP can use caching or its > local storage. > > So, what would that look like? > > > It=E2=80=99s not clear to me what the problem we are solving here is. Who= are we > trying to stop from reusing an assertion and why. The assertion is alread= y > bound to the specific private key and specific web origin. The IdP can bi= nd > it to a narrow time range if the IdP wants ( most do). I=E2=80=99m not se= eing the > big difference from reusing an assertion vs. asking the for a bunch of th= em. > The protocol that users the assertion may end up forking the same asserti= on > to many places regardless of what the browser does. > > Changing this so that the IdP see how many PeerConnections are formed see= ms > like it just reveal more usage information to the IdP and does not help > security. > > Assuming I am just not getting the problem and we do want to solve this = =E2=80=A6 I > is not clear to me how to make this all work with tls-id due to all the > bundle issues. Another approach would the browser greater a GUID for the > PeerConnection and that is passed in the IdP proxy code and the IdP can b= ind > it into the assertion or not but if it does bind into the assertion, then > the browser will only validate the assertion on the PeerConnection with > matching GUID. This is probably wrong and half baked as I don=E2=80=99t r= eally get > the problem. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Apr 30 08:20:42 2018 Return-Path: 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 765381205D3 for ; Mon, 30 Apr 2018 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com 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 b566ESTbQBwB for ; Mon, 30 Apr 2018 08:20:37 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.12]) (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 BF3E51200E5 for ; Mon, 30 Apr 2018 08:20:37 -0700 (PDT) Received: from [216.82.249.212] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-12.bemta-12.messagelabs.com id 29/8E-16074-54437EA5; Mon, 30 Apr 2018 15:20:37 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUxTZxTGe+693F6Va15uqxwrLrGOqGgbUUx INFGTzTCNm/rPYtW4y7ij1bZgbzF1S5Qao1BUyIJTSkwhNG5+bCSKX4kLUDNxihLrtwJaWyEi fhDnRGLQ3t7ix39P3t9z3ue85z0cLXSzBk7yuCWXU7Qb2dFMh7khzfRVTq9l1mDp2NwXjYOQe 7N9GHL/HN6pXUjnnfF3afOCwTdU3rWOAVhOW1Jszvwizw8p1t23H0Dx2RJPd2cPUwpRqw9Gcw x5TmH7o1atD0ZxAvmNwvNeUQECeQBYEWxhFMCSWXjz7zZK0XryLVY+60tomkzG/34PsEqBjpQ BXngZTprKAdu8i33AJQq2XdmiHDMkE70t7aBonqzBO/09jBoWo7BnRzergFFkBdZGGxPBQMbj 64tHk2HpeDcWSGgkeoxcvcSqehw+jg6nqP41eOBlKHluxL/6O5P+SRgOVIAShqSJwiO3ToEKT Phi715aBS2Ap32PaKVrJFl4d0ivyg3YcjlTtS9F37sQq9qDNL6tqk0GZGBd4JVWBcdYPNlcl6 LOtACrD49URAEbr9UkknXEgF3Xy6EKsvyfvM4f99EkAFjl9bL+xJzS8N+aGKOasjC47Z1W1TP wYP0TWtXzcP9QK+tP/kl1RSTpmYtP/hmAOuAOwzRZcm2SXKac2eZ8l63Q6naINrspO3u22SHJ slgo2cV82fxjkeMYxLdsq0YDp+Fq/eoQTOAo4zieaeixCGPziwo2W0XZus5VYpfkEGRwnBH5K XN6LUKaSyqUPD/Z7PFVHcHIpRr1/EwF83Kx6JBthSq6CHO4zqZfd9Fc2fPqXbTAOIuckiGdNy tWolitJc4PF42sfRgmGXQ8aDQaIbVYcjls7s95H6RzYNTxOcotqTan+0NeX7wVKt7KRIgprbj Fj8hQCtt108Pzl63qnXo8on9ouXf/jH0Pf73mi8rNDlPVEgpvNGyUhVuZy1oHov93cEfvxL58 Ot/avNLTFf7uF0FzAuqr+9ZG6LWX9hdsH1wwZeI3r84fWnLBse/s+u+3hrQnxkxurTR9/cfPG UONVPPurjdNB9vK5i6qm9Ffey6yaQz9tLx7nZGRrWJ2Fu2SxfcYH6VS8QMAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-2.tower-219.messagelabs.com!1525101635!184330264!1 X-Originating-IP: [207.46.163.17] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29541 invoked from network); 30 Apr 2018 15:20:36 -0000 Received: from mail-dm3nam03lp0017.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) (207.46.163.17) by server-2.tower-219.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 30 Apr 2018 15:20:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mU+9jdKOr7VzPd65djd9UP7ByZkfslcLQVYqgZ/LElQ=; b=VWgGN318cV+JucdhAbcwou4Y48H0/KrOfR+ROBnMDlnW8uOkaUd89gngUFaGSj/F1vTiHBs0zqZy7lM68D4o9ke2eV8RS0pG8te6fK8NQLe3tb8n8aGjNGogJoczry4svzxFCI5e9jmirOBI1XTm4xuEZsHPzVUK6/Qzw9Tl5Iw= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1182.namprd14.prod.outlook.com (10.173.101.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.20; Mon, 30 Apr 2018 15:20:33 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::c033:7973:d34d:e13f]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::c033:7973:d34d:e13f%17]) with mapi id 15.20.0715.018; Mon, 30 Apr 2018 15:20:33 +0000 From: Tim Hollebeek To: Martin Thomson , Cullen Jennings CC: RTCWeb IETF Thread-Topic: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) Thread-Index: AQHT0mSHdSosj9h75EqZv/oIt1x5RqQT4huAgAGAhZCAAQzegIACY3AAgACzY8A= Date: Mon, 30 Apr 2018 15:20:32 +0000 Message-ID: References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1182; 7:sekepx7AvsMB4ZAxyrdntj4sZA0cPMxXbTXRkPecHTKxo3MrGc/jvCGzcUP37aoBqM5q2AAJKJWD6JMX9jKIEQRD6TMLABR492UQIK8Vm9iDohmenzuPasDxd400zG8bu9wiGH8E316u9h9aeFnuV9Eo40vu5f8YAbVlNrBsOW9eb0rm0N5VwJJIax/0NOdGcPwVX7WshXxbfeFUOPoMBPdlSLyqnD9Rm/cb7ceRWVsGndWVGJtuFVJoVVKAoCRj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1182; x-ms-traffictypediagnostic: MWHPR14MB1182: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR14MB1182; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1182; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(396003)(376002)(39850400004)(39380400002)(199004)(189003)(51444003)(13464003)(316002)(9686003)(110136005)(97736004)(6306002)(74316002)(33656002)(229853002)(3660700001)(105586002)(7696005)(106356001)(99286004)(76176011)(53936002)(5660300001)(3280700002)(14454004)(66066001)(6116002)(55016002)(3846002)(5250100002)(11346002)(44832011)(305945005)(7736002)(39060400002)(186003)(476003)(99936001)(2900100001)(68736007)(81166006)(8676002)(486006)(81156014)(86362001)(26005)(2906002)(15650500001)(6506007)(6436002)(102836004)(59450400001)(53546011)(4326008)(8936002)(478600001)(966005)(446003)(25786009)(6246003)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1182; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Zy7GVSE74q7oISLTjG2B8vej74vf3p6a1yXiL+eaBVLoQGofpoTue9/TdtpUQLYeWEo+fdMCSi6UaaudvI9iRi1+Ns5d7KpUJW/taH5vFC5596Tzwo1oZfwy/hxYS78iaJfoCQOP1Cp8kG0kbvp5h+D/ZWqrcNPVspOXV6AB+h45oCgjUi0hfiKCUoOxSM8V spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_017E_01D3E075.3EF315B0" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 0594a227-defc-4681-e336-08d5aeadeaad X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0594a227-defc-4681-e336-08d5aeadeaad X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 15:20:33.0132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1182 Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 15:20:40 -0000 ------=_NextPart_000_017E_01D3E075.3EF315B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's entirely possible that there isn't actually a problem if you do all = the right things. But it's important that all those right things are actually required, = and the rationale is clearly explained in the security considerations. For example, doing = certificate=20 expiration checks, so that there isn't crypto data lying around that can = be used in=20 "interesting" ways in the future when the standard may have evolved into = something=20 else, seems like a good idea to me. I also think the musings in Martin's last paragraph make sense and are = headed in the=20 right direction. There's no harm in making protocols robust against = attack scenarios we haven't thought of yet. -Tim > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, April 30, 2018 12:30 AM > To: Cullen Jennings > Cc: Tim Hollebeek ; RTCWeb IETF > > Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb- > security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) >=20 > I agree with Cullen. >=20 > I would also point out that with an intended recipient, the IdP can = limit the > information that can be obtained from an assertion. If the assertion = were > provided to other than the intended recipient, the IdP could refuse to = provide > an identity. That requires authenticating the recipient as well, = which isn't > something we naturally assume, but the mechanisms for enabling that = are all in > place. >=20 > FWIW, I think that an abundance of caution suggests that limiting the = assertion > to a particular session is sensible. The problem there is that we = would need a > session identifier in order to do that. Until we discovered that = RTCCertificate > was portable, that was considered sufficient, I would prefer to remove = that > portability. Maybe we should consider adding an origin to = RTCCertificate that > would allow it to be moved to other origins, but not be used by them. >=20 > On Sun, Apr 29, 2018 at 2:01 AM, Cullen Jennings = wrote: > > > > Tim - that sounds about right but this is the part I don=E2=80=99t = get=E2=80=A6. > > > > All the identity assertion does is bind the public key from the TLS > > connection to the a name/identity. Think of it like a certificate = that > > binds my private key to name. Anyone can get my cert and pass it > > around however they want. That is fine. Similarly the assertion can = be > > passed around handed to bad people etc. But anyone using it need to > > match it with a TLS connection that does proof of possession of the > > private key that matches the public key. That private key is going = to > > be very narrowly scoped on what has access to it. People that want = to > > rely on this identity assertion have to be sure that they require = proof of > possession of private key. > > > > So I do not see the issue at all that the identity assertion, just > > like a normal X508 certificate, can be passed around. I=E2=80=99m = not getting > > whey this is Slightly Less than Awesome :-) > > > > I=E2=80=99m not arguing there is no problem, but I am not getting = what the > > problem is. > > > > Cullen > > > > > > > > On Apr 27, 2018, at 6:13 PM, Tim Hollebeek > > > > wrote: > > > > I=E2=80=99m going from my memory from the IETF 101 hackathon here, = so someone > > feel free to correct me if I=E2=80=99m remembering the details wrong = (I > > probably am for at least some of it), but as I recall it, the issue > > was essentially that when one requests an identity assertion, if one > > presents it to someone, the security properties are Awesome [TM] > > because only authorized persons can get an identity assertion from = the IDP. > > > > However, after one has presented an identity assertion to a > > potentially untrusted party, presentation of that assertion to > > additional parties is Slightly Less Than Awesome [TM], because the > > additional parties cannot distinguish between the person who > > legitimately obtained the identity assertion, and the party to which > > the identity assertion was previously presented. > > > > Various arguments were made that this is not a problem because the > > lifetime of identity assertions is short, with lifetimes on the = order > > of days to hours. There was also some discussion (before the issue > > was found) about if expiration of the relevant temporary = certificates > > needed to be checked at all. Call me crazy, but only having a few > > hours to carry out my attack doesn=E2=80=99t hinder me much as an = attacker! > > > > One solution that was discussed, which may or may not work for all = use > > cases and this certainly should be explored, was that identity > > assertions are cheap and therefore supporting the complexity of > > identity assertion re-use might not make sense. We discussed simply > > adding a nonce to the creation of identity assertions, so IDPs could > > enforce that they are validated only once, essentially turning them > > into bearer tokens. If the process fails (network hiccup, etc) it = is > > possible to transparently regenerate a new assertion and retry. = IIRC > > certain non-attack failure scenarios needed this retry logic anyway. > > > > If needed, I can go back and re-read the messages from that weekend = to > > help refresh my memory, but that=E2=80=99s what I remember. > > > > -Tim > > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen > > Jennings > > Sent: Thursday, April 26, 2018 9:03 PM > > To: Sean Turner > > Cc: RTCWeb IETF > > Subject: Re: [rtcweb] Addressing WGLC comments for > > draft-ietf-rtcweb-security-arch? (was Re: WGLC for > > draft-ietf-rtcweb-security-arch) > > > > > > > > > > On Apr 12, 2018, at 7:45 AM, Sean Turner wrote: > > > > 1) Tweak protocol to include an identifier to prevent reuse of > > assertion on every RTCPeerConnection: > > > > More complex sites frequently generate multiple RTCPeerConnection > > instances for their communications, especially for group > > conversations. If the browser requests an assertion once and they = use > > that value for every RTCPeerConnection, then that's OK. From my > > perspective, I would be happy modifying the protocol to include an > > identifier and prevent that; for this the IdP can use caching or its > > local storage. > > > > So, what would that look like? > > > > > > It=E2=80=99s not clear to me what the problem we are solving here = is. Who are > > we trying to stop from reusing an assertion and why. The assertion = is > > already bound to the specific private key and specific web origin. = The > > IdP can bind it to a narrow time range if the IdP wants ( most do). > > I=E2=80=99m not seeing the big difference from reusing an assertion = vs. asking the for a > bunch of them. > > The protocol that users the assertion may end up forking the same > > assertion to many places regardless of what the browser does. > > > > Changing this so that the IdP see how many PeerConnections are = formed > > seems like it just reveal more usage information to the IdP and does > > not help security. > > > > Assuming I am just not getting the problem and we do want to solve > > this =E2=80=A6 I is not clear to me how to make this all work with = tls-id due > > to all the bundle issues. Another approach would the browser greater = a > > GUID for the PeerConnection and that is passed in the IdP proxy code > > and the IdP can bind it into the assertion or not but if it does = bind > > into the assertion, then the browser will only validate the = assertion > > on the PeerConnection with matching GUID. This is probably wrong and > > half baked as I don=E2=80=99t really get the problem. > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > ------=_NextPart_000_017E_01D3E075.3EF315B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNDMwMTUyMDI5WjAvBgkqhkiG9w0BCQQxIgQgs7cF1NpI5124W/86akZseW6ifL/S hpgG0KOC9n/zt44wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAIj+YxTzxYfm16NDM+RPQE9BGp4RHTfzqpyt0+VA+/2NmnB5F3t0bRfTbW458QHDN1+pA8SL RXvQOEVpyXpFNYzR99xsA5ub6sVaMz0m71XU9U4kYPd3dChlaHqmc0B9lr2m+Th1y3udhmxjTDim MLlFRDvwbgZN3ksRlViqXa88uUNYaIwjoKSforyUpgLbNxBRsMRdbjmzyIMaiNZ57p1ptP1fJdTq boF24j1YsWh7rIAp4lVHQGxSlh6/61QrWKctgN0pvygHsDeGm9L66Tc0WhJSIv9LyULeUQAO1H4z xOF5qfZWOeNKZs12SRV14w1wrkMvdsqZUuVAEWcHm88AAAAAAAA= ------=_NextPart_000_017E_01D3E075.3EF315B0-- From nobody Mon Apr 30 15:03:27 2018 Return-Path: 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 42F91127275 for ; Mon, 30 Apr 2018 15:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 OEO3qBb6LDuH for ; Mon, 30 Apr 2018 15:03:24 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836021271FD for ; Mon, 30 Apr 2018 15:03:24 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id e20-v6so11916788iof.4 for ; Mon, 30 Apr 2018 15:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t8sJQf98tvxpK56wblWZcocADV3h62C4ymLh+MA5cjM=; b=JrNTNBjIA7MUZELCO81hJj9kxwH51NV+JotaZOxEZP/+5WwB9xW/HAbWzZ5pu36iwo BMA+wakI9Lldg/pDI+EskW7W1Eya/iUrJwTL58/D6zk32rGSIbs6u83t4dIfLHpQ1I5N Oj8AJrH5TyGUwiRa1npfJYjreu9urAzNRnXYs8n9L0sYjYuxghzjuqAnfaopRTdNHbKq hv3ADbiBfh5bQkyNTfYR/YhEGRlRN/EQC+9U3dyqDCuGN1cBkPIJ/iHLPL94f5pmxUmz ydk1jE89G5YS4oL0FYfYiu9EDGsj2LlSF3ujpJaIka6pzFU5FSOy/WqqPXnycZZiSylN mVow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t8sJQf98tvxpK56wblWZcocADV3h62C4ymLh+MA5cjM=; b=KvRojdW2SpX0LWOw6kuyx/Wzqfrwg1MO5HVEr5wD4et0kq3A8uxtMn/l1nGDkYGRj4 K07EfKfj874xN4NiAglgQ8a04UqyksOV+M9iQhS8DSVLx4nFX7hKxM1nI4JeI10qCAHO S4MQ8x756JLuC478xWVzFJC5rRHHfJppjsN0B7BZTVF4JB2Hnxfqx80xdKZ/Rg2UnUfg 7cVKZe/7tfsJS+n427fXBjvjOS7gczwEr3rZnAd24cAUbrictH+isvpjqPSg6CgbRjLS oGKLajWano0VH4BzhlPmXfyxAJHJtQeCwmZe4LF6qIPRS6v66B0+TqPSPg5wQh7z2vAD PAlA== X-Gm-Message-State: ALQs6tC6OtNbvKQnxIOnfjrUAulOSTmZLSqk7haeDjemaZtyz91jmyA6 t/fBSxOciJKBebQrf1rrolWri99vHtlqPaerScNtSA== X-Google-Smtp-Source: AB8JxZrQsOs7yY0X5OMj85K6Ib02D9FFw9RlmHeFnkehhls3e8y/w9qHtKmer+mnHgXyk0UGtUEO1FuDBbSv35foWm4= X-Received: by 2002:a6b:4514:: with SMTP id s20-v6mr14811758ioa.38.1525125803353; Mon, 30 Apr 2018 15:03:23 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> In-Reply-To: From: Justin Uberti Date: Mon, 30 Apr 2018 22:03:12 +0000 Message-ID: To: Cullen Jennings Cc: Nils Ohlmeier , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000bfbad9056b18054b" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 22:03:26 -0000 --000000000000bfbad9056b18054b Content-Type: text/plain; charset="UTF-8" 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.) 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. On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings 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. > > > --000000000000bfbad9056b18054b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Any TURN server provided by the browser is in effect a pro= xy, and forcing use of said proxy can be done either through firewall confi= g or explicit selection of Mode 4. (IOW, no new mode is needed.)

The document originally pointed at RETURN as an example of how suc= h TURN proxying could work, but was removed in order to avoid a dependency.=

On Fri, Apr 27,= 2018 at 11:22 AM Cullen Jennings <fluf= fy@iii.ca> wrote:


On Apr 17, 2018, at 3:15 AM, Justin Uberti <ju= berti=3D40google.com@dmarc.ietf.org> wrote:

IMO &qu= ot;trusting the TURN relay but not the application" is not a significa= nt 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.=C2=A0
=

--000000000000bfbad9056b18054b-- From nobody Mon Apr 30 15:21:36 2018 Return-Path: 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 055C312D964 for ; Mon, 30 Apr 2018 15:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 hX67n6GQlh_O for ; Mon, 30 Apr 2018 15:21:30 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93964127342 for ; Mon, 30 Apr 2018 15:21:30 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id k11-v6so6095457pgo.10 for ; Mon, 30 Apr 2018 15:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pz8BtFNkdGm7yrTmQzQ9lO/31Z+i0aSHrr+s1P2zJTo=; b=aaKMMGnE7aFIs5jv3LhWAFkjyWKd9GolbG9+KBKiewbbH/YUSvZ0G2K6bj2wacOeZP OfAPZJTEofP9+lNzRhG50rRT9hTj3bv+LVp23azr2SKGsLJpLO2gI8uRdXlIQd6Gegcb +7SIwpp6rOhQfdwnKa+GLjqCUA8xEHkmdwqgc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pz8BtFNkdGm7yrTmQzQ9lO/31Z+i0aSHrr+s1P2zJTo=; b=G2YWfq0gvztTukTJcXBQMwHXFjs9pH3O9T8pjweeyBTPqzDaDt/kxAqaX9XYQ//jkj V2tL4Llxe0bs8lR3wD4Y503X19Afcpy3F9DcJCYJpAPy84kSTASVsLVLyBul31EzDzlF 3mVz4x0gxRBcfcpBaRUOMNi/4kAfwWtJ2l6MohFzQDkcMrdhCkK9rkBldIDnZ8AZelLj JqUxfYNjakGnAHeAUYix/HPF+pzNK/qvH1jx8ya+IJz33vY9cUA73AZaZQWdyWS+EMeU hA8FS/WGy+glB0d3Ci2LDWb+r610bencbpStQcrEN1BPxY9BxVBdICHTvdcq/jQo92jD mCDA== X-Gm-Message-State: ALQs6tAhgRSVnMUEPZ9k24xR6zFF3YeM6tyEA3Af5XzLp9RPxm3vg/Xb PSCoLr1QG7yuu0jvnNBNO5OZDA== X-Google-Smtp-Source: AB8JxZqU3S9X/ZtHNtqVlxy2zy8ZcVxupVVwOpXqKb2nWBCpfEFi85cZ66LJAU6nhd6FTT3r3CsLRA== X-Received: by 2002:a63:7e5c:: with SMTP id o28-v6mr11090603pgn.194.1525126889748; Mon, 30 Apr 2018 15:21:29 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:9c6:eea3:f621:af89? ([2620:101:80fc:224:9c6:eea3:f621:af89]) by smtp.gmail.com with ESMTPSA id k83sm22456791pfg.153.2018.04.30.15.21.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 15:21:28 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A22F354E-DDF9-40F3-84A1-50FA191652E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 30 Apr 2018 15:21:26 -0700 In-Reply-To: Cc: Cullen Jennings , RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 22:21:35 -0000 --Apple-Mail=_A22F354E-DDF9-40F3-84A1-50FA191652E9 Content-Type: multipart/alternative; boundary="Apple-Mail=_12524E9F-73FE-4DBC-A3D9-1DFF69482314" --Apple-Mail=_12524E9F-73FE-4DBC-A3D9-1DFF69482314 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 30, 2018, at 15:03, Justin Uberti wrote: >=20 > 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 > wrote: >=20 >=20 >> On Apr 17, 2018, at 3:15 AM, Justin Uberti = > wrote: >>=20 >> IMO "trusting the TURN relay but not the application" is not a = significant enough benefit to merit adding specific functionality for. >>=20 >=20 > 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. >=20 >=20 --Apple-Mail=_12524E9F-73FE-4DBC-A3D9-1DFF69482314 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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=3D40google.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. 



= --Apple-Mail=_12524E9F-73FE-4DBC-A3D9-1DFF69482314-- --Apple-Mail=_A22F354E-DDF9-40F3-84A1-50FA191652E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrnluYACgkQY2o/VmzJ +KH6Ug//U2XsxP5cjSrr7ga4o2mrMvMkRfPU9cG65C0y4Zw/AX0FA/F+XB33rotN eHBPjZG3r3av1f1z0qnr/z0JC9eElnxJa9Et428OdZ+rSiz8NrshaRr8KVS2PnLa fpchgc+jrtxrL/+NvIVJ9eKlT3w9FfeavE0neaCOnax3WLK5wIJufyM1t/ZxOrqb McIFn6MkPjWT5uSWWXg3DGnaMXafq0XPdoKhrZJfQHtbvno8fX1vzmVrVvsa32Cg O50q+FbWslpr+DaKQSO7UNSKRbK3yT698StsN4UyBsUnXG57NN5NqXX4Nsmcvqot sh9vVMko0yjp+kueClwG6hw/0kUPYnYr4KoiIjrFFz/o2+fbD0UORpU6ZkatN0/K dr1BrVjR0eY37hf9qM/0jzFUD5NDItBmhHhTXuMYQn92ETIYafV7/evDI6D8s+9T fqUBgxko52a5CfpKhiagl2rWRRyS5dSFvOoSXKhSqqYTVUPwBpqhBnLbKqAukK0h bc2svBQtCtFSe6BDWoshWaz7QsLIk2UdpUrmrYFd9BuPuNszNqVV9rTn4+JaaJL1 kNKfCwwmEgqRJ07z9bYWxUcuLFjxBEqg79FbfyjREL+BjSyRNrHUyDtyuZdQOrpq K9eINhk3+9pD/OGSrDJVtHNMMP10RLeoqDG/B/Q3omHHLNsy2Ds= =zZQj -----END PGP SIGNATURE----- --Apple-Mail=_A22F354E-DDF9-40F3-84A1-50FA191652E9--