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

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. 

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. 

> On Apr 16, 2018, at 2:06 PM, 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.
> 
> 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. 
> 
> 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