From nobody Tue Aug 13 15:53:46 2019 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 F2E501208FE for ; Tue, 13 Aug 2019 15:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.79 X-Spam-Level: X-Spam-Status: No, score=-14.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 ZspURdUQA6YE for ; Tue, 13 Aug 2019 15:53:40 -0700 (PDT) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 414861208FD for ; Tue, 13 Aug 2019 15:53:40 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id b64so21807987vke.13 for ; Tue, 13 Aug 2019 15:53:40 -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; bh=8wX7bSTxWQ474CMS3UNSzFqsobZ5AF08feINB0UJgyU=; b=IVxOrhJetQYNsqLM8bcUUHpB1qeZHsLiRZkoRptJZX4bl5lOpAuK89vk5iKgIBYC1g uC2wjhUdGCGTrDNFBnyZg72zBrxZo8tVCoX7PNUT+VmdrtKS3AAOU3x8kTTrjIRWRdZK UyJG573xEWq/bUB329y7wr3uETYdWFAHBAC8Nsz4+h2xVH+pjTE+YBVaUtj6MLRyNI1j MMqMip/TPCtDdkSnSY4I/tPT9mntYRn0xAOtyHWVVM5+jfumRP6opXFA4+hO8ukQGwY1 iSZolGnc1TFcb+hELu8kxBLoVbYYqE6OKsgf1zeRr9amjbWy2ErzU3iHZ/Oo8ZrSfVJk ABDQ== 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; bh=8wX7bSTxWQ474CMS3UNSzFqsobZ5AF08feINB0UJgyU=; b=OyVSovkiCzSd9yzL6rjYNcT6hw+Mf5pom7TixH3ei+XvnOzmb3kxN/Cn2XYcqpheSD FYcESS1Ic14EliVAM1WMr4dYHdlKAgXQvf8AFiyiTb0+RygD2sF5sY+6DK3hb6uSyxeJ PQEsHf0VsxjknyI2jQYX9HWGV1QGZ+5wWN/EXfsIM61wQw51Pn8HFWb7hhCayVCqpVeu E+WU//BJs6gRmes/hLChlTh1oPqubNfd23Fe+0gMAdhvZdgNMhwjbSWtG/OwV8sF9tuZ ySCQjzJxsXrD8SH4vr9jeUErl3qYCgy7FhzMMOPniiRW7P5xU4szWqNoLXVUWHMAjCij HOWA== X-Gm-Message-State: APjAAAVKgO8GPplKTpbVtrFc0C49XZl1MRiYl3hCFezpQb1iRv9x1sIm wAFvdPm0GGF5XkzA+4MuNhNSnhlJTg+cbBD7ry5jg2jUnfY= X-Google-Smtp-Source: APXvYqzIe8NotxfviiCQG45OKUstAykSDtNQRhfimel5Bx5USCZVCu56v3At23IQgC1g482VbJlJraxTpl9uwDFpNWc= X-Received: by 2002:a1f:a44c:: with SMTP id n73mr6447248vke.76.1565736818464; Tue, 13 Aug 2019 15:53:38 -0700 (PDT) MIME-Version: 1.0 References: <1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797@googlegroups.com> In-Reply-To: <1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797@googlegroups.com> From: Justin Uberti Date: Tue, 13 Aug 2019 15:53:25 -0700 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000e0cb710590078251" Archived-At: Subject: [rtcweb] Fwd: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 13 Aug 2019 22:53:45 -0000 --000000000000e0cb710590078251 Content-Type: text/plain; charset="UTF-8" FYI, empirical results of deploying mDNS at scale. TL;DR: downside is low, ~2% impact to data channel connection rate between Chrome instances, somewhat higher when connecting to non-Chrome, likely due to issues handling mDNS candidates, which should be temporary. In the absence of any showstopper feedback, planning to roll this out fully later this month. ---------- Forwarded message --------- From: 'Qingsi Wang' via discuss-webrtc Date: Tue, Aug 13, 2019 at 2:33 PM Subject: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames To: discuss-webrtc Summary WebRTC currently lets web applications discover private IP addresses to enable direct connectivity between hosts on a local network. While private IP addresses do not uniquely identify browser users, they may still be used for tracking purposes. To prevent this misuse, private IP addresses returned by RTCPeerConnection will now be masked with mDNS hostnames in certain situations. While this change should be transparent to most WebRTC applications, some developers may need to update their client and backend services. This change is currently enabled for 50% of Chrome users, and is expected to fully roll out in August 2019 as part of the Chrome 76 release. WebRTC services can verify whether their services are affected by setting the following flag in Chrome 73 or later: chrome://flags/#enable-webrtc-hide-local-ips-with-mdns Why are we doing this? We have observed a trend of web sites using WebRTC specifically to obtain private IP addresses, presumably for tracking purposes. Accordingly, we have collaborated with other browser vendors to address this problem by using mDNS hostnames instead of private IP addresses in WebRTC, as described in this pending IETF spec . We have also experimentally verified the efficacy of the mDNS technique, following the initial announcement of this feature in January . Impact on applications When the feature is active, private IP addresses in ICE host candidates will be replaced by an mDNS hostname, e.g., 1f4712db-ea17-4bcf-a596-105139dfd8bf.local. Currently, this feature is active for all sites except those that have getUserMedia permissions, which are presumed to have a higher degree of user trust. WebRTC services that do not support addresses in the above format may be impacted, causing sessions to fail or use a less direct connection path. WebRTC services may be especially affected if they parse out addresses from RTCSessionDescription or RTCIceCandidate objects and assume those addresses are IP addresses, or have server components that do the same. In particular, older versions of the libnice library, used by some applications, do not parse such addresses properly. Impact on connectivity mDNS does not work in all situations; on some networks, mDNS may be disabled, or an endpoint may be too many hops away to resolve an mDNS hostname. In these cases, fallback to STUN will be required, and this may sometimes fail; as such, some amount of impact on connection success rate is to be expected. >From a broad analysis of peer-to-peer connections in the experimental deployment, the overall impact of mDNS on connectivity is modest, a 2% (relative) reduction in connection rate when mDNS was used by Chrome on both sides. In this population, the percentage of successful connections that used STUN on one side or the other increased from 94% to 97%, with a corresponding decrease in host-to-host connections. We believe the connectivity impact stems primarily from connections that previously worked host-to-host, but do not work with mDNS, and cannot fall back to STUN due to lack of hairpin support in the NAT. Somewhat surprisingly, for connections between Chrome and non-mDNS endpoints, we observed a larger impact, roughly 3% (relative) reduction in connection rate when the remote side supplied private IPs and 7% (relative) when the remote side supplied only public IPs. While mDNS should have zero impact in these cases, we believe this is explained by problems triggered by mDNS in third-party ICE stacks, including the aforementioned issues regarding parsing mDNS candidates as well as issues discovering peer-reflexive candidates from ICE connectivity checks. Given the success of the mDNS technique in combating tracking via private IP addresses, we believe this small impact on connection rate is an acceptable tradeoff. We will continue to investigate improvements to this technique to further minimize the downsides. General recommendations Improvements in Chrome are frequently rolled out as experiments and deploy first in Chrome Canary and the pre-stable Dev and Beta versions. Important experiments are also announced via email at the start of the rollout. We highly recommend WebRTC developers to: - Join blink-dev and discuss-webrtc to follow PSAs and other important announcements - Systematically test in Chrome Canary to see how your application behaves with upcoming Chrome changes - Provide feedback on the relevant bugs/forum threads -- --- You received this message because you are subscribed to the Google Groups "discuss-webrtc" group. To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797%40googlegroups.com . --000000000000e0cb710590078251 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, empirical results of deploying mDNS at scale. TL;DR: = downside is low, ~2% impact to data channel connection rate between Chrome = instances, somewhat higher when connecting to non-Chrome, likely due to iss= ues handling mDNS candidates, which should be temporary.=C2=A0

In the absence of any showstopper feedback, planning to roll this ou= t fully later this month.

---------- Forwarded message ---------
Fro= m: 'Qingsi Wang' vi= a discuss-webrtc <discuss-webrtc@googlegroups.com>
= Date: Tue, Aug 13, 2019 at 2:33 PM
Subject: [discuss-webrtc] PSA: Privat= e IP addresses exposed by WebRTC changing to mDNS hostnames
To: discuss-= webrtc <discuss-webrt= c@googlegroups.com>


Summary

WebRTC currently = lets web applications discover private IP addresses to enable direct connec= tivity between hosts on a local network. While private IP addresses do not = uniquely identify browser users, they may still be used for tracking purpos= es. To prevent this misuse, private IP addresses returned by RTCPeerConnect= ion will now be masked with mDNS hostnames in certain situations. While thi= s change should be transparent to most WebRTC applications, some developers= may need to update their client and backend services.=C2=A0


=

= This change is currently e= nabled for 50% of Chrome users, and is expected to fully roll out in August= 2019 as part of the Chrome 76 release. WebRTC services can verify whether = their services are affected by setting the following flag in Chrome 73 or l= ater: chrome://flags/#enable-webrtc-hide-local-ips-with-mdns


=

= Why are we= doing this?

We = have observed a trend of web sites using WebRTC specifically to obtain priv= ate IP addresses, presumably for tracking purposes. Accordingly, we have co= llaborated with other browser vendors to address this problem by using mDNS= hostnames instead of private IP addresses in WebRTC, as described in this pending IETF spec. We have also experimentally verified the efficacy of= the mDNS technique, following the initial anno= uncement of this feature in January.


Impact on applications

=

= When the feature is active, private IP addresses in ICE host candidates = will be replaced by an mDNS hostname, e.g., 1f4712db-ea17-4bcf-a596-105139dfd8bf.local. Currently, this feature is act= ive for all sites except those that have getUserMedia permissions, which ar= e presumed to have a higher degree of user trust.


WebRTC s= ervices that do not support addresses in the above format may be impacted, = causing sessions to fail or use a less direct connection path. WebRTC services may be especial= ly affected if they parse out addresses from RTCSessionDescription or RTCIc= eCandidate objects and assume those addresses are IP addresses, or have ser= ver components that do the same. In particular, older versions of the libni= ce library, used by some applications, do not parse such addresses properly= .


Impact on connectivity

mDNS= does not work in all situations; on some networks, mDNS may be disabled, o= r an endpoint may be too many hops away to resolve an mDNS hostname. In the= se cases, fallback to STUN will be required, and this may sometimes fail; a= s such, some amount of impact on connection success rate is to be expected.=

=C2=A0

From a broad analysis = of peer-to-peer connections in the experimental deployment, the overall imp= act of mDNS on connectivity is modest, a 2% (relative) reduction in connect= ion rate when mDNS was used by Chrome on both sides. In this population, th= e percentage of successful connections that used STUN on one side or the ot= her increased from 94% to 97%, with a corresponding decrease in host-to-hos= t connections. We believe the connectivity impact stems primarily from conn= ections that previously worked host-to-host, but do not work with mDNS, and= cannot fall back to STUN due to lack of hairpin support in the NAT.=

=C2=A0

Somewhat surprisingly, for co= nnections between Chrome and non-mDNS endpoints, we observed a larger impac= t, roughly 3% (relative) reduction in connection rate when the remote side = supplied private IPs and 7% (relative) when the remote side supplied only p= ublic IPs. While mDNS should have zero impact in these cases, we believe th= is is explained by problems triggered by mDNS in third-party ICE stacks, in= cluding the aforementioned issues regarding parsing mDNS candidates as well= as issues discovering peer-reflexive candidates from ICE connectivity chec= ks.

=C2=A0

Given the success o= f the mDNS technique in combating tracking via private IP addresses, we bel= ieve this small impact on connection rate is an acceptable tradeoff. We wil= l continue to investigate improvements to this technique to further minimiz= e the downsides.


General recommendations

Improvements in Chrome are frequently rolled o= ut as experiments and deploy first in Chrome Canary and the pre-stable Dev = and Beta versions. Important experiments are also announced via email at th= e start of the rollout. We highly recommend WebRTC developers to:

  • Join = blink-dev<= /span> and discuss-webrtc to follow PSAs and = other important announcements

  • Systematica= lly test in Chrome Canary to see how your application behaves with upcoming Chro= me changes

  • Provide feedback on the releva= nt bugs/forum threads

--

---
You received this message because you are subscribed to the Google Groups &= quot;discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https:= //groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e= 7797%40googlegroups.com.
--000000000000e0cb710590078251-- From nobody Wed Aug 14 10:32:46 2019 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 E5553120C6C for ; Wed, 14 Aug 2019 10:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 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, SPF_HELO_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=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=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 BzUhJCy61lHk for ; Wed, 14 Aug 2019 10:32:41 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 AEFD9120C6B for ; Wed, 14 Aug 2019 10:32:41 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id w10so53425504pgj.7 for ; Wed, 14 Aug 2019 10:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kTnozn1lOSKm0YBww1dWikC3CqOQuonfkezWx4aUaVU=; b=EhJJ5FSmytheMfHa/wo9ZLZYh8Dm6cYRbBgsAWBnhvb6vnhx2JjBu1YrYJYhy9F8Ic JEEzm3XihTIsK4Y0D4XqnA6ESiaPDrEOqSk7EtKiOF+CMWQ5XV4wQ0zQkuENqZxf454K eQDZSSrzy5U5r3abcucBlcjohz/Ypr2JeH4A8qL3Dg74Z2PJCoz7R26O9dPmCG682ooU 6BUdabO5iM/4ptyfMJt410Oofe69VorDZD0C5B+hGQmHje9lRB5x/mdm8Cn9qjJi+Vxk 8LFruiCkkCLFbGfbmYu2leTbTo4V/eFHlZz1h0c5AZCoPRjdmj5PJwH/ujiEItCnBz7K +hZQ== 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=kTnozn1lOSKm0YBww1dWikC3CqOQuonfkezWx4aUaVU=; b=mEWK6Rsxu0jqgOBCyw+4l/unU+HHTChHN6f5DRWY61rQUc5B7GWHS3Vo1gwgbYh/UY hD2OE97wZ1BREdPTzb75y6QZDmOATyLPNbEAadI+BU/XfQl/L4OH6RyzipwJU1V3/f0X xd1MJ48hkd+dRkHe/aWbjNr2TssLyCy/UWQxojGXzOMHonIsDYBF5DcCH+OS7MKFCH3y 9Aky+mUoRX3fmSS0j/c/Dm+8QzbItI1I9UZ2t0QUlkv6Jui35rIqC/c7vPhwk1H3bHWi zNixzG8tDxZJDPagZB6hqeyJYDjAy8VpbWX7Od00UU19szKWkSb//RGtbiQdJ34W/3Qj uuGA== X-Gm-Message-State: APjAAAUI0ch22uNaqgB86ldnA+HviIm2lVNB7wGt8elMRzRMjjbytsAo E+ki0yLP3dNVUJhIWkJf7C0bDQIYI0w= X-Google-Smtp-Source: APXvYqw4epg5UTsRTva7jf9Hy8Evf5ogqxrEpQEV5g2a9pu7AqWNtw2l7nshJ1cIVY+3AeszS5XBTg== X-Received: by 2002:a17:90b:911:: with SMTP id bo17mr793475pjb.40.1565803960545; Wed, 14 Aug 2019 10:32:40 -0700 (PDT) Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com. [209.85.214.180]) by smtp.gmail.com with ESMTPSA id k5sm407520pfg.167.2019.08.14.10.32.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Aug 2019 10:32:39 -0700 (PDT) Received: by mail-pl1-f180.google.com with SMTP id i2so51025991plt.1 for ; Wed, 14 Aug 2019 10:32:39 -0700 (PDT) X-Received: by 2002:a17:902:30d:: with SMTP id 13mr506660pld.284.1565803959041; Wed, 14 Aug 2019 10:32:39 -0700 (PDT) MIME-Version: 1.0 References: <1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797@googlegroups.com> In-Reply-To: From: Roman Shpount Date: Wed, 14 Aug 2019 13:32:36 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000c4453305901724e1" Archived-At: Subject: Re: [rtcweb] Fwd: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 14 Aug 2019 17:32:45 -0000 --000000000000c4453305901724e1 Content-Type: text/plain; charset="UTF-8" Hi Justin, In the statistics that you are providing, does this mean 2% of total connections attempts are affected or 2% of web sites which do data channel connections are affected? If this is the former, then a few applications that are responsible for large number of data channel connections that were updated to support mDNS will drown out things which are affected. Also, have you tested this on mobile platforms or is this just on desktop? I am really curios how well this will work on large dual stack mobile network. Have you looked separately on the connection failure rate when STUN servers are not used? Such applications would be affected by this change at a much higher degree. The PSA mentions STUN vs no-STUN but it is hard to decipher the actual failure rate in each of the cases. Have you collected any statistics on receive only media connections, such as web conferencing applications that allow the user to continue in listen only mode when user does not have or denies microphone access? In our case, this was the scenario which was most affected and deployments of fixes to work around this are still in progress with our customers. Has the interop with Firefox ESR ever been addressed? What is the proposed solution here? On the specification note, I would still consider rtcweb-mdns-ice-candidates to be fairly raw and not ready for production implementations. I would hope it would at least be ready for WGLC before something that implements it goes into production. At this point, there is high probability that the final version of this draft will require something somewhat different from what is currently implemented in Chrome now. Best Regards, _____________ Roman Shpount On Tue, Aug 13, 2019 at 6:54 PM Justin Uberti wrote: > FYI, empirical results of deploying mDNS at scale. TL;DR: downside is low, > ~2% impact to data channel connection rate between Chrome instances, > somewhat higher when connecting to non-Chrome, likely due to issues > handling mDNS candidates, which should be temporary. > > In the absence of any showstopper feedback, planning to roll this out > fully later this month. > > ---------- Forwarded message --------- > From: 'Qingsi Wang' via discuss-webrtc > Date: Tue, Aug 13, 2019 at 2:33 PM > Subject: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC > changing to mDNS hostnames > To: discuss-webrtc > > > Summary > > WebRTC currently lets web applications discover private IP addresses to > enable direct connectivity between hosts on a local network. While private > IP addresses do not uniquely identify browser users, they may still be used > for tracking purposes. To prevent this misuse, private IP addresses > returned by RTCPeerConnection will now be masked with mDNS hostnames in > certain situations. While this change should be transparent to most WebRTC > applications, some developers may need to update their client and backend > services. > > This change is currently enabled for 50% of Chrome users, and is expected > to fully roll out in August 2019 as part of the Chrome 76 release. WebRTC > services can verify whether their services are affected by setting the > following flag in Chrome 73 or later: > chrome://flags/#enable-webrtc-hide-local-ips-with-mdns > > Why are we doing this? > > We have observed a trend of web sites using WebRTC specifically to obtain > private IP addresses, presumably for tracking purposes. Accordingly, we > have collaborated with other browser vendors to address this problem by > using mDNS hostnames instead of private IP addresses in WebRTC, as > described in this pending IETF spec > . > We have also experimentally verified the efficacy of the mDNS technique, > following the initial announcement of this feature in January > > . > > Impact on applications > > When the feature is active, private IP addresses in ICE host candidates > will be replaced by an mDNS hostname, e.g., > 1f4712db-ea17-4bcf-a596-105139dfd8bf.local. Currently, this feature is > active for all sites except those that have getUserMedia permissions, which > are presumed to have a higher degree of user trust. > > WebRTC services that do not support addresses in the above format may be > impacted, causing sessions to fail or use a less direct connection path. WebRTC > services may be especially affected if they parse out addresses from > RTCSessionDescription or RTCIceCandidate objects and assume those addresses > are IP addresses, or have server components that do the same. In > particular, older versions of the libnice library, used by some > applications, do not parse such addresses properly.. > > Impact on connectivity > > mDNS does not work in all situations; on some networks, mDNS may be > disabled, or an endpoint may be too many hops away to resolve an mDNS > hostname. In these cases, fallback to STUN will be required, and this may > sometimes fail; as such, some amount of impact on connection success rate > is to be expected. > > > > From a broad analysis of peer-to-peer connections in the experimental > deployment, the overall impact of mDNS on connectivity is modest, a 2% > (relative) reduction in connection rate when mDNS was used by Chrome on > both sides. In this population, the percentage of successful connections > that used STUN on one side or the other increased from 94% to 97%, with a > corresponding decrease in host-to-host connections. We believe the > connectivity impact stems primarily from connections that previously worked > host-to-host, but do not work with mDNS, and cannot fall back to STUN due > to lack of hairpin support in the NAT. > > > > Somewhat surprisingly, for connections between Chrome and non-mDNS > endpoints, we observed a larger impact, roughly 3% (relative) reduction in > connection rate when the remote side supplied private IPs and 7% (relative) > when the remote side supplied only public IPs. While mDNS should have zero > impact in these cases, we believe this is explained by problems triggered > by mDNS in third-party ICE stacks, including the aforementioned issues > regarding parsing mDNS candidates as well as issues discovering > peer-reflexive candidates from ICE connectivity checks. > > > > Given the success of the mDNS technique in combating tracking via private > IP addresses, we believe this small impact on connection rate is an > acceptable tradeoff. We will continue to investigate improvements to this > technique to further minimize the downsides. > > General recommendations > > Improvements in Chrome are frequently rolled out as experiments and deploy > first in Chrome Canary and the pre-stable Dev and Beta versions. Important > experiments are also announced via email at the start of the rollout. We > highly recommend WebRTC developers to: > > - > > Join blink-dev > and > discuss-webrtc > to follow PSAs and other important announcements > - > > Systematically test in Chrome Canary > to see how your application > behaves with upcoming Chrome changes > - > > Provide feedback on the relevant bugs/forum threads > > -- > > --- > You received this message because you are subscribed to the Google Groups > "discuss-webrtc" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to discuss-webrtc+unsubscribe@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797%40googlegroups.com > > . > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000c4453305901724e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

In the stat= istics that you are providing, does this mean 2% of total connections attem= pts are affected or 2% of web sites which do data channel connections are a= ffected? If this is the former, then a few applications that are responsibl= e for large number of data channel connections that were updated to support= mDNS will drown out things which are affected.

Al= so, have you tested this on mobile platforms or is this just on desktop? I = am really curios how well this will work on large dual stack mobile network= .

Have you looked separately on the connection fai= lure rate when STUN servers are not used? Such applications would be affect= ed by this change at a much higher degree. The PSA mentions STUN vs no-STUN= but it is hard to decipher the actual failure rate in each of the cases.

Have you collected any statistics on receive only m= edia connections, such as web conferencing applications that allow the user= to continue in listen only mode when user does not have or denies micropho= ne access? In our case, this was the scenario which was most affected and d= eployments of fixes to work around this are still in progress with our cust= omers.

Has the interop with Firefox ESR ever been = addressed? What is the proposed solution here?

On = the specification note, I would still consider rtcweb-mdns-ice-candidates t= o be fairly raw and not ready for production implementations. I would hope = it would at least be ready for WGLC before something that implements it goe= s into production. At this point, there is high probability that the final = version of this draft will require something somewhat different from what i= s currently implemented in Chrome now.

Best Regard= s,
_____________
Roman Shpount

<= /div>

On Tue, Aug 13, 2019 at 6:54 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wr= ote:
FYI, empirical results of deploying mDNS at scale. TL;DR: downside is= low, ~2% impact to data channel connection rate between Chrome instances, = somewhat higher when connecting to non-Chrome, likely due to issues handlin= g mDNS candidates, which should be temporary.=C2=A0

In t= he absence of any showstopper feedback, planning to roll this out fully lat= er this month.

---------- Forwarded message ---------
From: 'Qingsi Wang' via discuss-web= rtc <discuss-webrtc@googlegroups.com>
Date: Tue, Aug 13, 2019 at 2:33 PM
Subject: [discuss-webrtc] PSA: P= rivate IP addresses exposed by WebRTC changing to mDNS hostnames
To: dis= cuss-webrtc <discuss-webrtc@googlegroups.com>


Summary

WebRTC currently lets web applications di= scover private IP addresses to enable direct connectivity between hosts on = a local network. While private IP addresses do not uniquely identify browse= r users, they may still be used for tracking purposes. To prevent this misu= se, private IP addresses returned by RTCPeerConnection will now be masked w= ith mDNS hostnames in certain situations. While this change should be trans= parent to most WebRTC applications, some developers may need to update thei= r client and backend services.=C2=A0


This change is currently enabled for 50% of Chrome= users, and is expected to fully roll out in August 2019 as part of the Chr= ome 76 release. WebRTC services can verify whether their services are affec= ted by setting the following flag in Chrome 73 or later: chrome://flags/#en= able-webrtc-hide-local-ips-with-mdns


Why are we doing this?

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma= l;vertical-align:baseline;white-space:pre-wrap">We have observed a trend of= web sites using WebRTC specifically to obtain private IP addresses, presum= ably for tracking purposes. Accordingly, we have collaborated with other br= owser vendors to address this problem by using mDNS hostnames instead of pr= ivate IP addresses in WebRTC, as described in this pendi= ng IETF spec. W= e have also experimentally verified the efficacy of the mDNS technique, fol= lowing the initial announcement of this feature= in January.


Impact on applications

When the feature is a= ctive, private IP addresses in ICE host candidates will be replaced by an m= DNS hostname, e.g.,= 1f47= 12db-ea17-4bcf-a596-105139dfd8bf.local. Currently, this feature is active for all sites except= those that have getUserMedia permissions, which are presumed to have a hig= her degree of user trust.


WebRTC services that do not supp= ort addresses in the above format may be impacted, causing sessions to fail= or use a less direct connection path. WebRTC services may be especially affected if they pars= e out addresses from RTCSessionDescription or RTCIceCandidate objects and a= ssume those addresses are IP addresses, or have server components that do t= he same. In particular, older versions of the libnice library, used by some= applications, do not parse such addresses properly..


Impact on connec= tivity

mDNS does not work in all = situations; on some networks, mDNS may be disabled, or an endpoint may be t= oo many hops away to resolve an mDNS hostname. In these cases, fallback to = STUN will be required, and this may sometimes fail; as such, some amount of= impact on connection success rate is to be expected.

=C2=A0

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;background-color:transparent= ;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:= baseline;white-space:pre-wrap">From a broad analysis of peer-to-peer connec= tions in the experimental deployment, the overall impact of mDNS on connect= ivity is modest, a 2% (relative) reduction in connection rate when mDNS was= used by Chrome on both sides. In this population, the percentage of succes= sful connections that used STUN on one side or the other increased from 94%= to 97%, with a corresponding decrease in host-to-host connections. We beli= eve the connectivity impact stems primarily from connections that previousl= y worked host-to-host, but do not work with mDNS, and cannot fall back to S= TUN due to lack of hairpin support in the NAT.

=C2=A0

Somewhat surprisingly, for connections between Ch= rome and non-mDNS endpoints, we observed a larger impact, roughly 3% (relat= ive) reduction in connection rate when the remote side supplied private IPs= and 7% (relative) when the remote side supplied only public IPs. While mDN= S should have zero impact in these cases, we believe this is explained by p= roblems triggered by mDNS in third-party ICE stacks, including the aforemen= tioned issues regarding parsing mDNS candidates as well as issues discoveri= ng peer-reflexive candidates from ICE connectivity checks.

=C2=A0=

Given the success of the mDNS technique= in combating tracking via private IP addresses, we believe this small impa= ct on connection rate is an acceptable tradeoff. We will continue to invest= igate improvements to this technique to further minimize the downsides.


General recommendations

Improvements in Chrome are frequently rolled out as experiments an= d deploy first in Chrome Canary and the pre-stable Dev and Beta versions. I= mportant experiments are also announced via email at the start of the rollo= ut. We highly recommend WebRTC developers to:

  • Join blink-dev and = discuss-webrtc to follow PSAs and other important = announcements

  • Systematically test in Chrome Canary to see how your application behaves with upcoming Chrome changes

  • Provide feedback on the relevant bugs/forum th= reads

--

---
You received this message because you are subscribed to the Google Groups &= quot;discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https:= //groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e= 7797%40googlegroups.com.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000c4453305901724e1-- From nobody Wed Aug 14 12:03:08 2019 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 2BD6C120DE8 for ; Wed, 14 Aug 2019 12:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.489 X-Spam-Level: X-Spam-Status: No, score=-17.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 B-Q7dnXl_mwc for ; Wed, 14 Aug 2019 12:02:47 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 46171120E1B for ; Wed, 14 Aug 2019 12:02:47 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id 62so12393549vsl.5 for ; Wed, 14 Aug 2019 12:02:47 -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=dxcEKpTTn7c1NWxJZcJaRlMhTPhXBuPnAm2NsABWy+A=; b=VAA9j1FYbkLjZinN8mlEs03kia3Dj91/TIVMJNuE5tyC+B8BHhhEFwBG6wv2TfRaAF s2o+/WU/TnE113PVNtAvZsAIo2+8U2Byh8/9ov5wuMgxTSy5xcQHHErYCE5pOE6z7R/g BWSxy3/dQF1sTuTi13ZuiH3/amGoZAp08jRyX6vnaHcZqny22wSqud/ZcdDjvogGDqyi K8YTXhSa0nnOnsFDxmvZdmbQ2CoAgw+FQabrDT9PzqvF9KL6hXj8aakpdVwotoXK+tY+ VLLSQzLZ4FdOscoRx0lNE8Nqr8wNzJeFTpght5QUlpv1sZbf6hVVAnBKHe7LPkMCRRfs t47g== 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=dxcEKpTTn7c1NWxJZcJaRlMhTPhXBuPnAm2NsABWy+A=; b=OXDUTzDMgAMQ2vRvMnK8udhyyxOjp+dgqhEIG+lpE9w5Df8wmloHEhxTqaPkSIoiPe 3EJXW6IjvXb0E2TesmV5eccXiLUuTcgR1JC/0khUI3/wAv1NRbtGpEcCoO9jaddpRgyt f2Uo+di7Bx5gLd7Tll8XT2Rz+9zpt/wyRun0u7YotnuVaEEGSi3d4WfWdq3HoCTyXJ0i 3F7JWkwPuYN98i5HH9BM5vUPEc8OxeYQzf293TJCOr8r0cY3XogkKUWpZ1AXVjGaslNN ahEV3ZkZrpFxVULL2nWJ7OUOnqQK49JI+nqL76jR982VMCElvrptNEL6NPLPEd5E3k7O rbJw== X-Gm-Message-State: APjAAAXFz5lD0bI1mFrFsyoTSPynEcIYYMfGj4IlRt3pTRJ1kdW2U9uI Awx5weiYz8BZrZKpXZ4pjAY22qbVb04mliH2VBu1IA== X-Google-Smtp-Source: APXvYqzlEuEmhnLNR4SmdobV8IbTCFUe2+boUsYjqPu9+2LhwrSe87FyZ7N1ObRjV3u7sEgnHbAtJjrOp3aJu+kXD8k= X-Received: by 2002:a67:8d84:: with SMTP id p126mr693574vsd.103.1565809365578; Wed, 14 Aug 2019 12:02:45 -0700 (PDT) MIME-Version: 1.0 References: <1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797@googlegroups.com> In-Reply-To: From: Justin Uberti Date: Wed, 14 Aug 2019 12:02:34 -0700 Message-ID: To: Roman Shpount Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000005fcbb05901867c5" Archived-At: Subject: Re: [rtcweb] Fwd: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC changing to mDNS hostnames X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 14 Aug 2019 19:03:06 -0000 --00000000000005fcbb05901867c5 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 14, 2019 at 10:32 AM Roman Shpount wrote: > Hi Justin, > > In the statistics that you are providing, does this mean 2% of total > connections attempts are affected or 2% of web sites which do data channel > connections are affected? If this is the former, then a few applications > that are responsible for large number of data channel connections that were > updated to support mDNS will drown out things which are affected. > 2% of total connection attempts. We separately considered Chrome->Chrome and Chrome->non-Chrome so we have some understanding of the impact on non-updated applications, and it seems to be modest. > > Also, have you tested this on mobile platforms or is this just on desktop? > I am really curios how well this will work on large dual stack mobile > network.. > At present we are only rolling this on desktop. Are you aware of a specific problem regarding mobile networks? > > Have you looked separately on the connection failure rate when STUN > servers are not used? Such applications would be affected by this change at > a much higher degree. The PSA mentions STUN vs no-STUN but it is hard to > decipher the actual failure rate in each of the cases. > Yes, but these cases are ~0.01% of the total. The impact is greater here, as expected; we are checking the exact numbers and can report more detail once we have vetted the data. > Have you collected any statistics on receive only media connections, such > as web conferencing applications that allow the user to continue in listen > only mode when user does not have or denies microphone access? In our case, > this was the scenario which was most affected and deployments of fixes to > work around this are still in progress with our customers. > These applications, being c2s, should be compatible with the mDNS technique, but we are aware that some upgrades to ICE stacks are necessary. If you are aware of large migrations that have not yet completed this would be useful for us to know so we can factor that in to our plans. > > Has the interop with Firefox ESR ever been addressed? What is the proposed > solution here? > Yes. Chrome 76 will use 0.0.0.0 in the c= line, and we will be able to measure the impact of this change as 76 rolls out. > > On the specification note, I would still consider > rtcweb-mdns-ice-candidates to be fairly raw and not ready for production > implementations. I would hope it would at least be ready for WGLC before > something that implements it goes into production. At this point, there is > high probability that the final version of this draft will require > something somewhat different from what is currently implemented in Chrome > now. > Waiting has its own costs, so in the absence of specific issues I don't think it makes sense to delay. If you are aware of significant problems with this technique, please raise them here or at https://github.com/rtcweb-wg/mdns-ice-candidates/issues. > > Best Regards, > _____________ > Roman Shpount > > > On Tue, Aug 13, 2019 at 6:54 PM Justin Uberti 40google.com@dmarc.ietf.org> wrote: > >> FYI, empirical results of deploying mDNS at scale. TL;DR: downside is >> low, ~2% impact to data channel connection rate between Chrome instances, >> somewhat higher when connecting to non-Chrome, likely due to issues >> handling mDNS candidates, which should be temporary. >> >> In the absence of any showstopper feedback, planning to roll this out >> fully later this month. >> >> ---------- Forwarded message --------- >> From: 'Qingsi Wang' via discuss-webrtc >> Date: Tue, Aug 13, 2019 at 2:33 PM >> Subject: [discuss-webrtc] PSA: Private IP addresses exposed by WebRTC >> changing to mDNS hostnames >> To: discuss-webrtc >> >> >> Summary >> >> WebRTC currently lets web applications discover private IP addresses to >> enable direct connectivity between hosts on a local network. While private >> IP addresses do not uniquely identify browser users, they may still be used >> for tracking purposes. To prevent this misuse, private IP addresses >> returned by RTCPeerConnection will now be masked with mDNS hostnames in >> certain situations. While this change should be transparent to most WebRTC >> applications, some developers may need to update their client and backend >> services. >> >> This change is currently enabled for 50% of Chrome users, and is expected >> to fully roll out in August 2019 as part of the Chrome 76 release. WebRTC >> services can verify whether their services are affected by setting the >> following flag in Chrome 73 or later: >> chrome://flags/#enable-webrtc-hide-local-ips-with-mdns >> >> Why are we doing this? >> >> We have observed a trend of web sites using WebRTC specifically to obtain >> private IP addresses, presumably for tracking purposes. Accordingly, we >> have collaborated with other browser vendors to address this problem by >> using mDNS hostnames instead of private IP addresses in WebRTC, as >> described in this pending IETF spec >> . >> We have also experimentally verified the efficacy of the mDNS technique, >> following the initial announcement of this feature in January >> >> . >> >> Impact on applications >> >> When the feature is active, private IP addresses in ICE host candidates >> will be replaced by an mDNS hostname, e.g., >> 1f4712db-ea17-4bcf-a596-105139dfd8bf.local. Currently, this feature is >> active for all sites except those that have getUserMedia permissions, which >> are presumed to have a higher degree of user trust. >> >> WebRTC services that do not support addresses in the above format may be >> impacted, causing sessions to fail or use a less direct connection path. WebRTC >> services may be especially affected if they parse out addresses from >> RTCSessionDescription or RTCIceCandidate objects and assume those addresses >> are IP addresses, or have server components that do the same. In >> particular, older versions of the libnice library, used by some >> applications, do not parse such addresses properly.. >> >> Impact on connectivity >> >> mDNS does not work in all situations; on some networks, mDNS may be >> disabled, or an endpoint may be too many hops away to resolve an mDNS >> hostname. In these cases, fallback to STUN will be required, and this may >> sometimes fail; as such, some amount of impact on connection success rate >> is to be expected. >> >> >> >> From a broad analysis of peer-to-peer connections in the experimental >> deployment, the overall impact of mDNS on connectivity is modest, a 2% >> (relative) reduction in connection rate when mDNS was used by Chrome on >> both sides. In this population, the percentage of successful connections >> that used STUN on one side or the other increased from 94% to 97%, with a >> corresponding decrease in host-to-host connections. We believe the >> connectivity impact stems primarily from connections that previously worked >> host-to-host, but do not work with mDNS, and cannot fall back to STUN due >> to lack of hairpin support in the NAT. >> >> >> >> Somewhat surprisingly, for connections between Chrome and non-mDNS >> endpoints, we observed a larger impact, roughly 3% (relative) reduction in >> connection rate when the remote side supplied private IPs and 7% (relative) >> when the remote side supplied only public IPs. While mDNS should have zero >> impact in these cases, we believe this is explained by problems triggered >> by mDNS in third-party ICE stacks, including the aforementioned issues >> regarding parsing mDNS candidates as well as issues discovering >> peer-reflexive candidates from ICE connectivity checks. >> >> >> >> Given the success of the mDNS technique in combating tracking via private >> IP addresses, we believe this small impact on connection rate is an >> acceptable tradeoff. We will continue to investigate improvements to this >> technique to further minimize the downsides. >> >> General recommendations >> >> Improvements in Chrome are frequently rolled out as experiments and >> deploy first in Chrome Canary and the pre-stable Dev and Beta versions. >> Important experiments are also announced via email at the start of the >> rollout. We highly recommend WebRTC developers to: >> >> - >> >> Join blink-dev >> >> and discuss-webrtc >> to follow >> PSAs and other important announcements >> - >> >> Systematically test in Chrome Canary >> to see how your application >> behaves with upcoming Chrome changes >> - >> >> Provide feedback on the relevant bugs/forum threads >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "discuss-webrtc" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to discuss-webrtc+unsubscribe@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e7797%40googlegroups.com >> >> . >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --00000000000005fcbb05901867c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 14, 2019 at 10:32 AM Roma= n Shpount <roman@telurix.com>= ; wrote:
Hi Justin,

In the statistics = that you are providing, does this mean 2% of total connections attempts are= affected or 2% of web sites which do data channel connections are affected= ? If this is the former, then a few applications that are responsible for l= arge number of data channel connections that were updated to support mDNS w= ill drown out things which are affected.

2% of total connection=C2=A0attempts. We separately conside= red Chrome->Chrome and Chrome->non-Chrome so we have some understandi= ng of the impact on non-updated applications, and it seems to be modest.
<= div dir=3D"ltr">

Also, have you tested this on mobile pl= atforms or is this just on desktop? I am really curios how well this will w= ork on large dual stack mobile network..

At present we are only rolling this on desktop. Are you awa= re of a specific problem regarding mobile networks?=C2=A0

Have you looked separately on the connection failure rate = when STUN servers are not used? Such applications would be affected by this= change at a much higher degree. The PSA mentions STUN vs no-STUN but it is= hard to decipher the actual failure rate in each of the cases.
=

Yes, but these cases are ~0.01% of t= he total. The impact is greater here, as expected; we are checking the exac= t numbers and can report more detail once we have vetted the data.=C2=A0


Have you collected any stati= stics on receive only media connections, such as web conferencing applicati= ons that allow the user to continue in listen only mode when user does not = have or denies microphone access? In our case, this was the scenario which = was most affected and deployments of fixes to work around this are still in= progress with our customers.

=
These applications, being c2s, should be compatible with the mDNS tech= nique, but we are aware that some upgrades to ICE stacks are necessary. If = you are aware of large migrations that have not yet completed this would be= useful for us to know so we can factor that in to our plans.

Has the interop with Firefox ESR ever been addressed? = What is the proposed solution here?

=
Yes. Chrome 76 will use 0.0.0.0 in the c=3D line, and we will be= able to measure the impact of this change as 76 rolls out.
<= div>
On the specification note, I would still consider rtcweb= -mdns-ice-candidates to be fairly raw and not ready for production implemen= tations. I would hope it would at least be ready for WGLC before something = that implements it goes into production. At this point, there is high proba= bility that the final version of this draft will require something somewhat= different from what is currently implemented in Chrome now.

Waiting has its own costs, so in the ab= sence of specific issues I don't think it makes sense to delay. If you = are aware of significant problems with this technique, please raise them he= re or at=C2=A0https://github.com/rtcweb-wg/mdns-ice-candidates/issues.=C2=A0

Best Regards,
_____________
Roman Shpount


On Tue, Aug = 13, 2019 at 6:54 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> w= rote:
FYI, empirical results of deploying mDNS at scale. TL;DR: downside= is low, ~2% impact to data channel connection rate between Chrome instance= s, somewhat higher when connecting to non-Chrome, likely due to issues hand= ling mDNS candidates, which should be temporary.=C2=A0

I= n the absence of any showstopper feedback, planning to roll this out fully = later this month.

---------- Forwarded message ---------
From: 'Qingsi Wang' via discuss-= webrtc <discuss-webrtc@googlegroups.com>
Date: Tue, Aug 13, 2019 at 2:33 PM
Subject: [discuss-webrtc] PSA= : Private IP addresses exposed by WebRTC changing to mDNS hostnames
To: = discuss-webrtc <discuss-webrtc@googlegroups.com>


Summa= ry

WebRTC curren= tly lets web applications discover private IP addresses to enable direct co= nnectivity between hosts on a local network. While private IP addresses do = not uniquely identify browser users, they may still be used for tracking pu= rposes. To prevent this misuse, private IP addresses returned by RTCPeerCon= nection will now be masked with mDNS hostnames in certain situations. While= this change should be transparent to most WebRTC applications, some develo= pers may need to update their client and backend services.=C2=A0

=

This change is current= ly enabled for 50% of Chrome users, and is expected to fully roll out in Au= gust 2019 as part of the Chrome 76 release. WebRTC services can verify whet= her their services are affected by setting the following flag in Chrome 73 = or later: chrome://flags/#enable-webrtc-hide-local-ips-with-mdns

=

Why ar= e we doing this?

We have observed a trend of web sites using WebRTC specifically to obtain = private IP addresses, presumably for tracking purposes. Accordingly, we hav= e collaborated with other browser vendors to address this problem by using = mDNS hostnames instead of private IP addresses in WebRTC, as described in <= /span>this pending IETF spec. We have also experimentally verified the efficac= y of the mDNS technique, following = the initial = announcement of this feature in January.


Impact on applications=

When the feature is active, private IP addresses in ICE host candida= tes will be replaced by an mDNS hostname, e.g., 1f4712db-ea17-4bcf-a596-105139dfd8bf.local. Currently, this feature is= active for all sites except those that have getUserMedia permissions, whic= h are presumed to have a higher degree of user trust.


Web= RTC services that do not support addresses in the above format may be impac= ted, causing sessions to fail or use a less direct connection path. = WebRTC services may be esp= ecially affected if they parse out addresses from RTCSessionDescription or = RTCIceCandidate objects and assume those addresses are IP addresses, or hav= e server components that do the same. In particular, older versions of the = libnice library, used by some applications, do not parse such addresses pro= perly..


Impact on connectivity

mDNS does not work in all situations; on some networks, mDNS may be disab= led, or an endpoint may be too many hops away to resolve an mDNS hostname. = In these cases, fallback to STUN will be required, and this may sometimes f= ail; as such, some amount of impact on connection success rate is to be exp= ected.

=C2=A0

From a broad ana= lysis of peer-to-peer connections in the experimental deployment, the overa= ll impact of mDNS on connectivity is modest, a 2% (relative) reduction in c= onnection rate when mDNS was used by Chrome on both sides. In this populati= on, the percentage of successful connections that used STUN on one side or = the other increased from 94% to 97%, with a corresponding decrease in host-= to-host connections. We believe the connectivity impact stems primarily fro= m connections that previously worked host-to-host, but do not work with mDN= S, and cannot fall back to STUN due to lack of hairpin support in the NAT.<= /span>

=C2=A0

Somewhat surprisingly, = for connections between Chrome and non-mDNS endpoints, we observed a larger= impact, roughly 3% (relative) reduction in connection rate when the remote= side supplied private IPs and 7% (relative) when the remote side supplied = only public IPs. While mDNS should have zero impact in these cases, we beli= eve this is explained by problems triggered by mDNS in third-party ICE stac= ks, including the aforementioned issues regarding parsing mDNS candidates a= s well as issues discovering peer-reflexive candidates from ICE connectivit= y checks.

=C2=A0

Given the suc= cess of the mDNS technique in combating tracking via private IP addresses, = we believe this small impact on connection rate is an acceptable tradeoff. = We will continue to investigate improvements to this technique to further m= inimize the downsides.


General recommendations

Improvements in Chrome are frequently ro= lled out as experiments and deploy first in Chrome Canary and the pre-stabl= e Dev and Beta versions. Important experiments are also announced via email= at the start of the rollout. We highly recommend WebRTC developers to:

  • Jo= in = blink-dev and discuss-webrtc to follow= PSAs and other important announcements

  • S= ystematically test in Chrome C= anary to see how your application behaves with upc= oming Chrome changes

  • Provide feedback on = the relevant bugs/forum threads

--

---
You received this message because you are subscribed to the Google Groups &= quot;discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https:= //groups.google.com/d/msgid/discuss-webrtc/1d124cbb-f9d3-4ba4-9bb0-0099cf3e= 7797%40googlegroups.com.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000005fcbb05901867c5-- From nobody Wed Aug 14 12:12:29 2019 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 9334A120DF6 for ; Wed, 14 Aug 2019 12:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 tI3AEwNHsIGH for ; Wed, 14 Aug 2019 12:12:26 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 38D73120DF2 for ; Wed, 14 Aug 2019 12:12:26 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id o101so508369ota.8 for ; Wed, 14 Aug 2019 12:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wAqJM5pr43gVVKXVtoRXH1sOI+Gudo9LhrgdXJJX9jc=; b=dbASmnVOHenYqtXfHvKkXtvHHyhyQMjjnHEUUy2x9P97SK0Z5hdo8gNdvfqe/szxxA SEqN02bb+b+E7+sSKcFDO49lVzojJ5jf0r2lLizaSMi4tZwVxzfCIGG0bEoavPVw5uUz MP86VQKSZStGwGeVdiQKXRPQhHFMNzLc9ilMtoXlVx9ptWGViH3VLsH412WxctdJRxTm weiDq4r0CqDgTms4pWasmg9N+pzzyCaVEJgT+oXW0rpfKTzjXDp/8zYcOCjDuIvl0Mhd 5sVhjgqWVWO3sCjkTC3Qpgi9G2DBuEnYsfGY+9EahE3U9xQa/K1im8ESEsVW+AMuBARM DBGw== 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=wAqJM5pr43gVVKXVtoRXH1sOI+Gudo9LhrgdXJJX9jc=; b=g9ZnMmfInlfTgc6v70T2EcG0O7B5CxCG9nn/l2Ps2TCc49es15buctEMKMpvjK6no9 HYKfS6VV4OIUKKYN0fzdC3PWUmQK0jalH9lOVDelI2CCxX7LBZOEgF7MU58+OAL+lxg5 1TuBE/ftlaDLU4pCizDmaVoFJFF1sp7rhpf3SrurQOSI4ty4W/471MnaFbcDeX1/7nMA sfb0eSq043yBWpJgmYIg2KlBc+PbBVIl5lD/ixVH48PbKN6YQdu75k9xmY0fur1UzXfH gjO6HZEpFAD9VtalRgX+rZbCUkGXyUYpr7cNwdJxMmQrD7BqSPs5sIBz0Zf8mhhYDLra 6uxw== X-Gm-Message-State: APjAAAWX31v2KLL7TmAmwlr1iE8JF5+Co0Ywl/I7XsSlTa88Ih1BJE0A kWV+NmqneSZmtpzrH1P7wwltMFXK9uX3VCOsDgEMtLHg X-Google-Smtp-Source: APXvYqycKo08TmX5qzyQk6h/0fX6VX/TYXH2u0TwoAJEk0tKO6Lqb8eoVOI0DpWT9+1Y530CQzU040Kooi/6Mmclsh4= X-Received: by 2002:a6b:720e:: with SMTP id n14mr1536256ioc.139.1565809945047; Wed, 14 Aug 2019 12:12:25 -0700 (PDT) MIME-Version: 1.0 From: Ted Hardie Date: Wed, 14 Aug 2019 12:11:58 -0700 Message-ID: To: RTCWeb IETF , Harald Alvestrand , Gonzalo Camarillo , Magnus Westerlund , Mary Barnes , Sean Turner , Cullen Jennings , Alissa Cooper , Adam Roach Content-Type: multipart/alternative; boundary="0000000000008f7fcf0590188909" Archived-At: Subject: [rtcweb] The late, great RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 14 Aug 2019 19:12:29 -0000 --0000000000008f7fcf0590188909 Content-Type: text/plain; charset="UTF-8" For those of you who like to flip to the end of a book: with the entry of the final dependencies of its core work into the RFC Editor queue, the working group is closing. The mailing list will remain open for discussion, and any trailing documents will be processed by Adam as AD sponsored or headed to DISPATCH. For those of you who wish to take a journey, open your books to IETF 80, in Prague ; it's late March and Spring is in the air. A large and plucky band of folks are trying to work out if it is possible to have real time communications in a browser without any plugins. The resulting work will require protocol changes, new APIs, and a new level of cooperation between the IETF and the W3C. The outlook is optimistic; the IESG agrees to a mailing list on April 4, 2011 and to make the effort a working group on May 3rd. Our first meeting as a working group was IETF 81 : The rooms were large, the energy palpable, and the optimism at a quick and decisive effort had resulted in a charter with milestones like this: Goals and Milestones: Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to W3C Sep 2011 Architecture and Security, Privacy, and Threat Model document(s) to IESG as Informational Sep 2011 Use cases, Scenarios, and Requirements for RTCWeb document sent to IESG as Informational Dec 2011 RTCWeb protocol profiles and Media format specification(s) to IESG as PS Dec 2011 Information elements and events APIs Input to W3C Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) Ladies and gentleman, we are a bit late. During the time this working group was active, we went through multiple ADs: Gonzalo was succeeded by Alissa and then by Adam. The Area we were in, RAI, was merged with APPS to create ART. Magnus, one of the original WG chairs, had a baby and was succeeded by Sean, who then had a baby (Actually, make that two babies in both cases). Cullen was eventually poached by his management to serve as CTO of Webex. The group was also prolific. My personal archive for the mailing list shows just over 9000 messages, (though this is slightly inflated by my putting chair messages in there as well.) The cluster of documents that is the output of the work in RTCWEB and in the working groups on whom we had dependencies has become legendary: cluster 238 gave rise to both some extraordinary dwell times (the data protocol and channel drafts are at 1679 days, more than four and half years) and some RFC editor innovations (the creation of a cluster mailing list, so that AUTH48 changes are coordinated across groups). While the working group tussled over interoperability with non-browser systems and then on the implications of that decision for codecs, we lost some time. We appear, however, to have made up for it: WebRTC is available in well over a billion applications or endpoints. By the simple metrics of rough consensus and running code, it is a runaway success. On behalf of all the chairs and area directors who were part of the journey, for your contributions to that success, whether as document author, minute taker, jabber scribe, interim host, comment maker or poser of questions, many thanks, Ted Hardie --0000000000008f7fcf0590188909 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For those of you who like to flip to the end of a boo= k:=C2=A0 with the=20 entry of the final dependencies of its core work into the RFC Editor=20 queue, the working group is closing.=C2=A0 The mailing list will remain ope= n=20 for discussion, and any trailing documents will be processed by Adam as=20 AD sponsored or headed to DISPATCH.=C2=A0

For= those of you who wish to take a journey, open your books to IETF 80, in= Prague; it's late March and Spring is in the air.=C2=A0 A large and plucky ban= d of=20 folks are trying to work out if it is possible to have real time=20 communications in a browser without any plugins.=C2=A0 The resulting work= =20 will require protocol changes, new APIs, and a new level of cooperation=20 between the IETF and the W3C.=C2=A0 The outlook is optimistic; the IESG agr= ees to a mailing list on April 4, 2011 and to make the effort a working group=20 on May 3rd.=C2=A0

Our first meeting as a work= ing group was=C2=A0 IETF 81:=C2=A0 The rooms were large, the energy palpable, and the optimism at a quick and= =20 decisive effort had resulted in a charter with milestones like this:
<= div>
Goals and Milestones:

Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C

Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to=C2= =A0 W3C

Sep 2011 Architecture and Security, Privacy, and Threat Model document(s) t= o IESG as Informational

Sep 2011 Use cases, Scenarios, and Requirements for RTCWeb document sent to= IESG as Informational

Dec 2011 RTCWeb protocol profiles and Media format specification(s) to IESG= as PS

Dec 2011 Information elements and events APIs Input to W3C

Apr 2012 API to Protocol mapping document submitted to the IESG as Informat= ional (if needed)

Ladies and gentleman, we ar= e a bit late.=C2=A0

During the time this working group was active, we went through multiple ADs:=20 Gonzalo was succeeded by Alissa and then by Adam.=C2=A0 The Area we were in= , RAI, was merged with APPS to create ART.=C2=A0 Magnus, one of the origina= l=20 WG chairs, had a baby and was succeeded by Sean, who then had a baby=20 (Actually, make that two babies in both cases).=C2=A0 Cullen was eventually= =20 poached by his management to serve as CTO of Webex.=C2=A0=C2=A0
<= div>
The group was also prolific.=C2=A0 My personal archive for the mailing list=20 shows just over 9000 messages, (though this is slightly inflated by my=20 putting chair messages in there as well.)=C2=A0=C2=A0 The cluster of docume= nts=20 that is the output of the work in RTCWEB and in the working groups on=20 whom we had dependencies has become legendary: cluster 238 gave rise to=20 both some extraordinary dwell times (the data protocol and channel=20 drafts are at 1679 days, more than four and half years) and some RFC=20 editor innovations (the creation of a cluster mailing list, so that=20 AUTH48 changes are coordinated across groups).

While the working group tussled over interoperability with non-browser=20 systems and then on the implications of that decision for codecs, we=20 lost some time.=C2=A0 We appear, however,=C2=A0 to have made up for it:=C2= =A0 WebRTC is=20 available in well over a billion applications or endpoints.=C2=A0 By the=20 simple metrics of rough consensus and running code, it is a runaway=20 success.

On behalf of all the chairs and area=20 directors who were part of the journey, for your contributions to that=20 success, whether as document author, minute taker, jabber scribe,=20 interim host, comment maker or poser of questions,=C2=A0
many thanks,

Ted Hardie
--0000000000008f7fcf0590188909-- From nobody Wed Aug 14 14:10:38 2019 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 EED3A120D44; Wed, 14 Aug 2019 14:10:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" Cc: rtcweb@ietf.org, sean+ietf@sn3rd.com, ted.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <156581702990.2418.1755511117066158341.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2019 14:10:29 -0700 Archived-At: Subject: [rtcweb] WG Action: Conclusion of Real-Time Communication in WEB-browsers (rtcweb) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 14 Aug 2019 21:10:30 -0000 The Real-Time Communication in WEB-browsers (rtcweb) WG in the Applications and Real-Time Area has concluded. The IESG contact persons are Adam Roach, Barry Leiba, and Alexey Melnikov. The mailing list will remain open. -- For those of you who like to flip to the end of a book: with the entry of the final dependencies of its core work into the RFC Editor queue, the working group is closing. The mailing list will remain open for discussion, and any trailing documents will be processed by Adam as AD sponsored or headed to DISPATCH. For those of you who wish to take a journey, open your books to IETF 80, in Prague ;; it's late March and Spring is in the air. A large and plucky band of folks are trying to work out if it is possible to have real time communications in a browser without any plugins. The resulting work will require protocol changes, new APIs, and a new level of cooperation between the IETF and the W3C. The outlook is optimistic; the IESG agrees to a mailing list on April 4, 2011 and to make the effort a working group on May 3rd. Our first meeting as a working group was IETF 81 : The rooms were large, the energy palpable, and the optimism at a quick and decisive effort had resulted in a charter with milestones like this: Goals and Milestones: Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to W3C Sep 2011 Architecture and Security, Privacy, and Threat Model document(s) to IESG as Informational Sep 2011 Use cases, Scenarios, and Requirements for RTCWeb document sent to IESG as Informational Dec 2011 RTCWeb protocol profiles and Media format specification(s) to IESG as PS Dec 2011 Information elements and events APIs Input to W3C Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) Ladies and gentleman, we are a bit late. During the time this working group was active, we went through multiple ADs: Gonzalo was succeeded by Alissa and then by Adam. The Area we were in, RAI, was merged with APPS to create ART. Magnus, one of the original WG chairs, had a baby and was succeeded by Sean, who then had a baby (Actually, make that two babies in both cases). Cullen was eventually poached by his management to serve as CTO of Webex. The group was also prolific. My personal archive for the mailing list shows just over 9000 messages, (though this is slightly inflated by my putting chair messages in there as well.) The cluster of documents that is the output of the work in RTCWEB and in the working groups on whom we had dependencies has become legendary: cluster 238 gave rise to both some extraordinary dwell times (the data protocol and channel drafts are at 1679 days, more than four and half years) and some RFC editor innovations (the creation of a cluster mailing list, so that AUTH48 changes are coordinated across groups). While the working group tussled over interoperability with non-browser systems and then on the implications of that decision for codecs, we lost some time. We appear, however, to have made up for it: WebRTC is available in well over a billion applications or endpoints. By the simple metrics of rough consensus and running code, it is a runaway success. On behalf of all the chairs and area directors who were part of the journey, for your contributions to that success, whether as document author, minute taker, jabber scribe, interim host, comment maker or poser of questions, many thanks, Ted Hardie From nobody Wed Aug 14 14:21:34 2019 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 A5D63120D44 for ; Wed, 14 Aug 2019 14:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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=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 hls7u2uT1liS for ; Wed, 14 Aug 2019 14:21:30 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 D74601201B7 for ; Wed, 14 Aug 2019 14:21:30 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id m12so172144plt.5 for ; Wed, 14 Aug 2019 14:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rVq+bQsOamnUtmYqPPQaWBnzi4527AoiHNtSgeNV1TI=; b=thTVUao8J9kpMcFbLNitb1YrGorExIIacZJ5KvA0QjTqQZLrtxQdeL8cX/QSyZxeU0 OThFO9cYNTVmWnztvNXyqYz+dlNAyZacxx70Bw1N2egxOQSaoRH4+M+f3PqMh2IzitA0 /ThNCNyK0hbkjsUvm9wppQ6dVWplvqjHcxeULBD0Cn0dL67erSzqk6PwJg/wWYvfFhKN k5wamHDNfdbli2ZdoMBF13cmengzPeUBule21Sx2rfREO0aS8Zalg0HnNwsX8P8YQmpx ievDTwRRhEZeVVZx3zeFEutQ+d9TrCs/TdP6iTt8cdAIV+inh9/pFqAQLpDwreM56QxM dhIA== 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; bh=rVq+bQsOamnUtmYqPPQaWBnzi4527AoiHNtSgeNV1TI=; b=r1onTREyJjJ2NE0HHmY5GEAdIll6uYJ2Dp7qIoZlr7vBUZ/Vfw4JCL365lId2V5FUu fNWCJIH2ZGb3bt0MPHvxj7dpzPDwFphgy9OUgSBrBT8KtDLCUqowgBZJB5Sb6cnkKg+u 4n8tlTy5fYo9/CyDWwAiVs1GqbRIL/ehQdVnC81FkSIMZemoBPGGBo6KhPEcrDdJOMhn nAIHRPlieEIahgAS6UhY5nWVmfiamq8J2kV1PyEF+dPlJNmzFO5Gvivu/CXdJO0ZL9+O BHLwpH00Rs84X+zd1D5hGUKPn/aDUdBojqUHCJa9h9EaHsSCf34Xpid6axZld4tfFVwe EilA== X-Gm-Message-State: APjAAAWBV/2O9L5ygBXtPnlwfutgSDzK2kOzFmHjL1/ibG+by9aDd0S8 e1BL8Pjx0uVPmCqx95DAca/JsScn0Wo= X-Google-Smtp-Source: APXvYqxRlZao4ZA7pftv2Qv+jbPl/pbl+1vuycPZ4XPEL3bJlILSUG4vKTFZF6kzgRfq06fYzVMVqg== X-Received: by 2002:a17:902:8492:: with SMTP id c18mr1284103plo.279.1565817689642; Wed, 14 Aug 2019 14:21:29 -0700 (PDT) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com. [209.85.210.180]) by smtp.gmail.com with ESMTPSA id x1sm640020pjo.4.2019.08.14.14.21.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Aug 2019 14:21:28 -0700 (PDT) Received: by mail-pf1-f180.google.com with SMTP id 196so104617pfz.8 for ; Wed, 14 Aug 2019 14:21:28 -0700 (PDT) X-Received: by 2002:a63:7a06:: with SMTP id v6mr963595pgc.115.1565817688099; Wed, 14 Aug 2019 14:21:28 -0700 (PDT) MIME-Version: 1.0 References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> In-Reply-To: From: Roman Shpount Date: Wed, 14 Aug 2019 17:21:16 -0400 X-Gmail-Original-Message-ID: Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000015199305901a57f4" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 14 Aug 2019 21:21:33 -0000 --00000000000015199305901a57f4 Content-Type: text/plain; charset="UTF-8" Hi All, Since RTCWEB is closed, I am going to ask once again: Should we move draft-ietf-rtcweb-mdns-ice-candidates to mmusic? I know people are unhappy with mmusic draft development speed, but if enough people participate, we should be able to complete mdns draft quickly and potentially develop an additional draft which will clarify generic FQDN candidate processing procedures. Thank You, _____________ Roman Shpount On Sun, Jul 7, 2019 at 3:47 AM Harald Alvestrand wrote: > On 7/6/19 10:15 PM, Roman Shpount wrote: > > > Given mmusic's traditional processing speed, I am not sure there's any >> point in formally moving the document at this point. >> > > It is especially slow when none of the people interested in the specific > feature (FQDN in ICE candidates) participate in the discussion. So far this > looks like this feature is going to be shipped regardless of what anybody > thinks about it and without even attempting to discuss it in the group > which is responsible for this functionality. > > My favorite examples are -msid (initial version May 2012, IESG evaluation > June 2016); -sdp-simulcast (initial version April 2015, IESG evaluation May > 2018); -bundle-negotiation (initial version October 2011, IESG evaluation > February 2018). > > Each of these has its own history, but when a group is capable of > discussing a draft for seven years before it is IESG-ready, I question the > effectieness of moving drafts into that group. > > > Best Regards, > _____________ > Roman Shpount > > > > -- > Surveillance is pervasive. Go Dark. > > --00000000000015199305901a57f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Since RTCWEB is closed, I am go= ing to ask once again: Should we move=C2=A0draft-ietf-rtcweb-mdns-ice-candi= dates to mmusic?

I know people are unhappy with mm= usic draft development speed, but if enough people participate, we should b= e able to complete mdns draft quickly and potentially develop an additional= draft which will clarify generic FQDN candidate processing procedures.

Thank You,
_____________
= Roman Shpount


On Sun, Jul 7, 2019 at 3:47 AM Harald Al= vestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 7/6/19 10= :15 PM, Roman Shpount wrote:
=20

Given mmusic= 9;s traditional processing speed, I am not sure there's any
point in formally moving the document at this point.

It is especially slow when none of the people interested in the specific feature (FQDN in ICE candidates) participate in the discussion. So far this looks like this feature is going to be shipped regardless of what anybody thinks about it and without even attempting to discuss it in the group which is responsible for this functionality.

My favorite examples are -msid (initial version May 2012, IESG evaluation June 2016); -sdp-simulcast (initial version April 2015, IESG evaluation May 2018); -bundle-negotiation (initial version October 2011, IESG evaluation February 2018).

Each of these has its own history, but when a group is capable of discussing a draft for seven years before it is IESG-ready, I question the effectieness of moving drafts into that group.


Best Regards,
_____________
Roman Shpount
=C2=A0


--=
=20
Surveillance is pervasive. Go Dark.
--00000000000015199305901a57f4-- From nobody Wed Aug 14 15:18:23 2019 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 B7EF81208E3 for ; Wed, 14 Aug 2019 15:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 kxLOPubc0NlS for ; Wed, 14 Aug 2019 15:18:19 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 A770A120F14 for ; Wed, 14 Aug 2019 15:18:19 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id i7so380406vsp.0 for ; Wed, 14 Aug 2019 15:18: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=HRoC/KcSrGAXRzVUWIsfglfz1g1pTaAa68D91AAqBAQ=; b=qowVQYnZD2K9IMCwWNgkkaL1S5ZXMkBvC+yuCukx3qw7LyCjujyOWOSGNqlRk8UsZe vB50x1iWMYqvClBUecTiPC/EL45hV0A0K9rK+VEf9wthhZ5jxxWiGbTTqdv6b0/UeImT xF21ypHG0yO33E5bUelp1YaDpZSI7US5eIcVwxbOS4WdfDd7yZ7LDMa79AaVXWOved6v SE+Oh8EeVWZlFFQafBirSrchD4hcQK1h7stUf4VRPFYutxvE0r9FqXg7nCiZen4xA9IC zwzbpKd9QHbyDw7iq5M74eRBGkhJKH3kNv0yPc9nXgPyGl3N95WFxrtTi4vp0f90Egje wcMg== 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=HRoC/KcSrGAXRzVUWIsfglfz1g1pTaAa68D91AAqBAQ=; b=Rq7G6EA2NRodnrl0I305JswYQzclnfisptQvRH8M7yNOOQxnUUQ2SzINYP0ZsCR+Cs RwMRME/LFIy9VKjvxTdWMOJEwBEkyXNr4iprQ6oRnUkdiVnr/h7ja51fkgFYpNQmXpsM 4BOcna/8k17qSophh28mRIIil6lvJm0r5RGErwTZjRjAPZR1vDcJ9TGOyb5B/8R9Ph1n Y1RzBXdV/wlTsXkXFWZ90zrzgyHBJUqek9ZvhBCsq52fIgqjADvmc8vhxYOytLVGwQ5G hTHPmhkqBMUnyOqdm9VD6C2TbAzJWKObh1Y7Ouz4e7xX5UAuwYeYk8S/xtXcqquPy3fb CkWA== X-Gm-Message-State: APjAAAWZ+5oHK9H6iYj124LyNbgfpeA27wvNuymmLIeNYS0fiO+1T+9f NOJN8RGdho+gQTAF/Vm+YT5UGSebxU9XZlt534qw+1bdAOFIrg== X-Google-Smtp-Source: APXvYqw3l5200I60NCoerdPD3Ihvcd2JV3vrysUqKeDj7UbzbGvVvhJX4gLZ1KM3ZEogCgF3ZZWy5gJajcQTeNmHF+s= X-Received: by 2002:a67:ff0a:: with SMTP id v10mr1609254vsp.1.1565821098038; Wed, 14 Aug 2019 15:18:18 -0700 (PDT) MIME-Version: 1.0 References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> In-Reply-To: From: Justin Uberti Date: Wed, 14 Aug 2019 15:18:06 -0700 Message-ID: To: Roman Shpount Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000055158405901b22a2" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 14 Aug 2019 22:18:22 -0000 --00000000000055158405901b22a2 Content-Type: text/plain; charset="UTF-8" My understanding is that draft-ietf-rtcweb-mdns-ice-candidates is going to be AD sponsored. On Wed, Aug 14, 2019 at 2:21 PM Roman Shpount wrote: > Hi All, > > Since RTCWEB is closed, I am going to ask once again: Should we > move draft-ietf-rtcweb-mdns-ice-candidates to mmusic? > > I know people are unhappy with mmusic draft development speed, but if > enough people participate, we should be able to complete mdns draft quickly > and potentially develop an additional draft which will clarify generic FQDN > candidate processing procedures. > > Thank You, > _____________ > Roman Shpount > > > On Sun, Jul 7, 2019 at 3:47 AM Harald Alvestrand > wrote: > >> On 7/6/19 10:15 PM, Roman Shpount wrote: >> >> >> Given mmusic's traditional processing speed, I am not sure there's any >>> point in formally moving the document at this point. >>> >> >> It is especially slow when none of the people interested in the specific >> feature (FQDN in ICE candidates) participate in the discussion. So far this >> looks like this feature is going to be shipped regardless of what anybody >> thinks about it and without even attempting to discuss it in the group >> which is responsible for this functionality. >> >> My favorite examples are -msid (initial version May 2012, IESG evaluation >> June 2016); -sdp-simulcast (initial version April 2015, IESG evaluation May >> 2018); -bundle-negotiation (initial version October 2011, IESG evaluation >> February 2018). >> >> Each of these has its own history, but when a group is capable of >> discussing a draft for seven years before it is IESG-ready, I question the >> effectieness of moving drafts into that group. >> >> >> Best Regards, >> _____________ >> Roman Shpount >> >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000055158405901b22a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My understanding is that draft-ietf-rtcweb-mdns-ice-candid= ates is going to be AD sponsored.

On Wed, Aug 14, 2019 at 2:21 PM Roman Shpo= unt <roman@telurix.com> wrot= e:
Hi All,

Since RTCWEB is closed, I am going to ask on= ce again: Should we move=C2=A0draft-ietf-rtcweb-mdns-ice-candidates to mmus= ic?

I know people are unhappy with mmusic draft de= velopment speed, but if enough people participate, we should be able to com= plete mdns draft quickly and potentially develop an additional draft which = will clarify generic FQDN candidate processing procedures.

Thank You,
_____________Roman Shpount


On Sun, Jul 7, 2019 at 3:47 AM Harald A= lvestrand <har= ald@alvestrand.no> wrote:
=20 =20 =20
On 7/6/19 10:15 PM, Roman Shpount wrote:
=20

Given mmusic= 9;s traditional processing speed, I am not sure there's any
point in formally moving the document at this point.

It is especially slow when none of the people interested in the specific feature (FQDN in ICE candidates) participate in the discussion. So far this looks like this feature is going to be shipped regardless of what anybody thinks about it and without even attempting to discuss it in the group which is responsible for this functionality.

My favorite examples are -msid (initial version May 2012, IESG evaluation June 2016); -sdp-simulcast (initial version April 2015, IESG evaluation May 2018); -bundle-negotiation (initial version October 2011, IESG evaluation February 2018).

Each of these has its own history, but when a group is capable of discussing a draft for seven years before it is IESG-ready, I question the effectieness of moving drafts into that group.


Best Regards,
_____________
Roman Shpount
=C2=A0


--=20
Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000055158405901b22a2-- From nobody Wed Aug 14 15:40:50 2019 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 3641E1208EF for ; Wed, 14 Aug 2019 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 ry7Ibr8pSCMF for ; Wed, 14 Aug 2019 15:40:47 -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 79D5E120917 for ; Wed, 14 Aug 2019 15:40:47 -0700 (PDT) Received: from MacBook-Pro.roach.at (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 x7EMegVV050165 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 14 Aug 2019 17:40:45 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1565822445; bh=r3RB2bN+F/BldyUF1+LPyZffMV6R4FyIvehOK/ZnQtc=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Abkn1FfWfa71AYGXjWfx6Z9SqAZOuIon/O9Pu/hzDNuc9Lwvm8Ig1vFmP6/6URkkt nnG8q0UxSl79PfOLzNuknEpuayWHiDiyWtneYf9KbcKl005K98A40WK7d45d0DKgxI lDJgGX1WBKKLVFiv3bMuSf7GzhYQYC+2A9+vEzLE= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Justin Uberti , Roman Shpount Cc: RTCWeb IETF References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> From: Adam Roach Message-ID: <7e63dd04-1b11-7118-f158-b48bda0d892d@nostrum.com> Date: Wed, 14 Aug 2019 17:40:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CFB1239DB597513E75D49218" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 14 Aug 2019 22:40:49 -0000 This is a multi-part message in MIME format. --------------CFB1239DB597513E75D49218 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin is correct regarding the current plan. /a On 8/14/19 5:18 PM, Justin Uberti wrote: > My understanding is that draft-ietf-rtcweb-mdns-ice-candidates is > going to be AD sponsored. > > On Wed, Aug 14, 2019 at 2:21 PM Roman Shpount > wrote: > > Hi All, > > Since RTCWEB is closed, I am going to ask once again: Should we > move draft-ietf-rtcweb-mdns-ice-candidates to mmusic? > > I know people are unhappy with mmusic draft development speed, but > if enough people participate, we should be able to complete mdns > draft quickly and potentially develop an additional draft which > will clarify generic FQDN candidate processing procedures. > > Thank You, > _____________ > Roman Shpount > > > On Sun, Jul 7, 2019 at 3:47 AM Harald Alvestrand > > wrote: > > On 7/6/19 10:15 PM, Roman Shpount wrote: >> >> Given mmusic's traditional processing speed, I am not >> sure there's any >> point in formally moving the document at this point. >> >> >> It is especially slow when none of the people interested in >> the specific feature (FQDN in ICE candidates) participate in >> the discussion. So far this looks like this feature is going >> to be shipped regardless of what anybody thinks about it and >> without even attempting to discuss it in the group which is >> responsible for this functionality. > > My favorite examples are -msid (initial version May 2012, IESG > evaluation June 2016); -sdp-simulcast (initial version April > 2015, IESG evaluation May 2018); -bundle-negotiation (initial > version October 2011, IESG evaluation February 2018). > > Each of these has its own history, but when a group is capable > of discussing a draft for seven years before it is IESG-ready, > I question the effectieness of moving drafts into that group. > > >> Best Regards, >> _____________ >> Roman Shpount > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > 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 --------------CFB1239DB597513E75D49218 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Justin is correct regarding the current plan.

/a

On 8/14/19 5:18 PM, Justin Uberti wrote:
My understanding is that draft-ietf-rtcweb-mdns-ice-candidates is going to be AD sponsored.

On Wed, Aug 14, 2019 at 2:21 PM Roman Shpount <roman@telurix.com> wrote:
Hi All,

Since RTCWEB is closed, I am going to ask once again: Should we move draft-ietf-rtcweb-mdns-ice-candidates to mmusic?

I know people are unhappy with mmusic draft development speed, but if enough people participate, we should be able to complete mdns draft quickly and potentially develop an additional draft which will clarify generic FQDN candidate processing procedures.

Thank You,
_____________
Roman Shpount


On Sun, Jul 7, 2019 at 3:47 AM Harald Alvestrand <harald@alvestrand.no> wrote:
On 7/6/19 10:15 PM, Roman Shpount wrote:

Given mmusic's traditional processing speed, I am not sure there's any
point in formally moving the document at this point.

It is especially slow when none of the people interested in the specific feature (FQDN in ICE candidates) participate in the discussion. So far this looks like this feature is going to be shipped regardless of what anybody thinks about it and without even attempting to discuss it in the group which is responsible for this functionality.

My favorite examples are -msid (initial version May 2012, IESG evaluation June 2016); -sdp-simulcast (initial version April 2015, IESG evaluation May 2018); -bundle-negotiation (initial version October 2011, IESG evaluation February 2018).

Each of these has its own history, but when a group is capable of discussing a draft for seven years before it is IESG-ready, I question the effectieness of moving drafts into that group.


Best Regards,
_____________
Roman Shpount
 


-- 
Surveillance is pervasive. Go Dark.
_______________________________________________
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


--------------CFB1239DB597513E75D49218-- From nobody Wed Aug 14 15:46:18 2019 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 6C236120F37 for ; Wed, 14 Aug 2019 15:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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=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 Hc5EUDzFZEzY for ; Wed, 14 Aug 2019 15:46:14 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 1B9A8120E9B for ; Wed, 14 Aug 2019 15:46:14 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id u17so337756pgi.6 for ; Wed, 14 Aug 2019 15:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+97p7ORrHGqmvYy6YC+zHI5jFuTqlp9uRxAfBjsVObA=; b=I8vF415LRLr5A7O1LVFmNZBpS8HHt+W+Mfdg6P9IKqvedHiTSkRWuomHrczqNjAD8t JJl+5lXn80pF5/w2hy6sp09vdUoZBMMToaLC5k4P8TZLScpiy4jusv0wA3txN/sujba/ y9vDFNIAps5s1su4fHKWahxIzjcg+JZnxEQrrb/JPeK5QAsi5L6G5KIuiCFeEAod+Y8N nLC+yIhtLHXmpVCO/860Qrt589+6muA6DhwPfe53Cq0S/DzjG0A4IWpPHOWjJM+kvy8C U8NruNMZKwFhumwNo4LBJYgYlV6AIHqGKPQzL2e1UXZzfSnfeB6uyWWgVZo9w/1xTTjH OKzg== 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=+97p7ORrHGqmvYy6YC+zHI5jFuTqlp9uRxAfBjsVObA=; b=anuQSJ0FO6tRD3LC7U4dhEUvfvJgh+iH/9AyW/MVMA9UAWu7zZIKfJLBczUK/r4xyi PRjAvFPfHFD4VierKf+pILa3PEVZbF5uyJzwTORHz7UgrS+uhDDPaX/6MGi2ajH271tw A2Jz9hWgfus9AWWM0Ei/N293K9TWLWYpwqzW38dURSoUg1/sLhDwDTAYUruHDvOoGtDf bDLXmeXrhaGASySJSc23l8UzdKC8elNcB7Ur1Tu8le7aNWJqF2y5tC/6BdGTHSh1uInI bpSl9nKHiwaKnGcTYiNdUODnYtv8xheeaxm7PZmk4c1nme9gDBiypOcQDdjUxOa1w2ft NGLA== X-Gm-Message-State: APjAAAVjwds+15h8Wzdsxen0vgjSPdK4Gn5DH1/TXjei+Nu7r1rUHFeO S7/Scw9Xl+8Wluq5rFLX0vCdsH6o3TQ= X-Google-Smtp-Source: APXvYqylSnfQQoZ3L55FNLi8aBvwF46IxxazYw+Cwo1340c5GsFthd9oNLrGHJ22cUcRpf7NdQSlrQ== X-Received: by 2002:a63:ed55:: with SMTP id m21mr1159812pgk.343.1565822773097; Wed, 14 Aug 2019 15:46:13 -0700 (PDT) Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com. [209.85.210.170]) by smtp.gmail.com with ESMTPSA id ce7sm33405pjb.16.2019.08.14.15.46.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Aug 2019 15:46:12 -0700 (PDT) Received: by mail-pf1-f170.google.com with SMTP id w16so237797pfn.7 for ; Wed, 14 Aug 2019 15:46:11 -0700 (PDT) X-Received: by 2002:a63:7a06:: with SMTP id v6mr1192236pgc.115.1565822771483; Wed, 14 Aug 2019 15:46:11 -0700 (PDT) MIME-Version: 1.0 References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> <7e63dd04-1b11-7118-f158-b48bda0d892d@nostrum.com> In-Reply-To: <7e63dd04-1b11-7118-f158-b48bda0d892d@nostrum.com> From: Roman Shpount Date: Wed, 14 Aug 2019 18:45:57 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000135a4605901b86f4" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 14 Aug 2019 22:46:17 -0000 --000000000000135a4605901b86f4 Content-Type: text/plain; charset="UTF-8" Just want to remind everyone that a new draft will need to be written to update ice-sip-sdp to enable sending FQDN in ICE candidates before mdns-ice-candidate can be released. I would assume it would need to happen in mmusic. Also, mdns-ice-candidate is not really rtcweb specific. IP address privacy concerns addressed this draft apply to any peer-to-peer communication protocol that uses ICE. _____________ Roman Shpount On Wed, Aug 14, 2019 at 6:40 PM Adam Roach wrote: > Justin is correct regarding the current plan. > > /a > > On 8/14/19 5:18 PM, Justin Uberti wrote: > > My understanding is that draft-ietf-rtcweb-mdns-ice-candidates is going to > be AD sponsored. > > On Wed, Aug 14, 2019 at 2:21 PM Roman Shpount wrote: > >> Hi All, >> >> Since RTCWEB is closed, I am going to ask once again: Should we >> move draft-ietf-rtcweb-mdns-ice-candidates to mmusic? >> >> I know people are unhappy with mmusic draft development speed, but if >> enough people participate, we should be able to complete mdns draft quickly >> and potentially develop an additional draft which will clarify generic FQDN >> candidate processing procedures. >> >> Thank You, >> _____________ >> Roman Shpount >> >> >> On Sun, Jul 7, 2019 at 3:47 AM Harald Alvestrand >> wrote: >> >>> On 7/6/19 10:15 PM, Roman Shpount wrote: >>> >>> >>> Given mmusic's traditional processing speed, I am not sure there's any >>>> point in formally moving the document at this point. >>>> >>> >>> It is especially slow when none of the people interested in the specific >>> feature (FQDN in ICE candidates) participate in the discussion. So far this >>> looks like this feature is going to be shipped regardless of what anybody >>> thinks about it and without even attempting to discuss it in the group >>> which is responsible for this functionality. >>> >>> My favorite examples are -msid (initial version May 2012, IESG >>> evaluation June 2016); -sdp-simulcast (initial version April 2015, IESG >>> evaluation May 2018); -bundle-negotiation (initial version October 2011, >>> IESG evaluation February 2018). >>> >>> Each of these has its own history, but when a group is capable of >>> discussing a draft for seven years before it is IESG-ready, I question the >>> effectieness of moving drafts into that group. >>> >>> >>> Best Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> >>> -- >>> Surveillance is pervasive. Go Dark. >>> >>> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > --000000000000135a4605901b86f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just want to remind everyone that a new draft will need to= be written to update ice-sip-sdp to enable sending FQDN in ICE candidates = before mdns-ice-candidate can be released. I would assume it would need to = happen in mmusic.

Also, mdns-ice-candidate is not really= rtcweb specific. IP address privacy concerns addressed this draft apply to= any peer-to-peer communication protocol that uses ICE.
_____________
Roman Shpount


On Wed, Aug 14, 2= 019 at 6:40 PM Adam Roach <adam@nost= rum.com> wrote:
=20 =20 =20
Justin is co= rrect regarding the current plan.

/a

On 8/14/19 5= :18 PM, Justin Uberti wrote:
=20
My understanding is that draft-ietf-rtcweb-mdns-ice-candidates is going to be AD sponsored.

On Wed, Aug 14, 2019 at 2:21 PM Roman Shpount <roman@telurix.com> wrote:
Hi All,

Since RTCWEB is closed, I am going to ask once again: Should we move=C2=A0draft-ietf-rtcweb-mdns-ice-candidates to mmusic?

I know people are unhappy with mmusic draft development speed, but if enough people participate, we should be able to complete mdns draft quickly and potentially develop an additional draft which will clarify generic FQDN candidate processing procedures.

Thank You,
_____________
Roman Shpount


On Sun, Jul 7, 2019 at 3:47 AM Harald Alvestrand <harald@alvestrand.no> wrote:
On 7/6/19 10:15 PM, Roman Shpount wrote:

Giv= en mmusic's traditional processing speed, I am not sure there's any
point in formally moving the document at this point.

It is especially slow when none of the people interested in the specific feature (FQDN in ICE candidates) participate in the discussion. So far this looks like this feature is going to be shipped regardless of what anybody thinks about it and without even attempting to discuss it in the group which is responsible for this functionality.

My favorite examples are -msid (initial version May 2012, IESG evaluation June 2016); -sdp-simulcast (initial version April 2015, IESG evaluation May 2018); -bundle-negotiation (initial version October 2011, IESG evaluation February 2018).

Each of these has its own history, but when a group is capable of discussing a draft for seven years before it is IESG-ready, I question the effectieness of moving drafts into that group.


Best Regards,
_____________
Roman Shpount
=C2=A0


--=20
Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.= org
https://www.ietf.org/mailman/listinfo/rtcweb

= 
____________=
___________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.iet=
f.org/mailman/listinfo/rtcweb


--000000000000135a4605901b86f4-- From nobody Wed Aug 14 22:34:52 2019 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 09D8A12002F for ; Wed, 14 Aug 2019 22:34:50 -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, DKIMWL_WL_HIGH=-0.001, 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=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 ztCqmZvOORel for ; Wed, 14 Aug 2019 22:34:46 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50071.outbound.protection.outlook.com [40.107.5.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D092C120019 for ; Wed, 14 Aug 2019 22:34:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hNEgpK1hx5+G6pSrhvLDfa/o3rKJgloTO3o/OGxlhZNtf87CFYTdjZ+o7CrDZtzNQKNfOeygzTnQ03oNBaeLQP773V/cUBjdOsh/1cqJ3Xy/bfGTR94YGCOA+1tP+NCX2CnkcYZQ3ToW0kE88cAwjPiu548Z6wrsPEm5yJa8bmAUc2Yxdxwjqf6hG4MTg28VgFg8AqdaKouEEDQwBzqGR6V1u4jRZuczR7HVzFDCQF0Md1I4mRFrsXDmSaDlwe+MX/mzyDk0gWs231qKnV9zWScsHq2LodgSJogEOuKErUOOJRv/4sB4hGUG+av2btvMjUtBW54cmcpZTVuYH6LYAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jUF9w1mB4O+IrwjUm9vvAxYX5VJhVxaReOUOETG7XFM=; b=fn3weuDpLgJpVRF7LEq7EY0P20FXo8QS/zFChPGoRJEUWOuurXTH49JVII35TbEDXKEezdvE/0AW5wEUM4LWc35g6wXO22YUDba2i7HQIDF8+ZtD3ow+hNb05fa4g3vi78llfJcJNiPKvhp6tiiaCWv8ErrcuMEHUswpA1O0kjFBwQT85xZbKRvE5UQ28ViH2jWylGlRrwzu/mEpLSUzbQLYJZHNF97pghNw8MpD5ffBjLhNLRT2A7C/3x0XM0fy0oOfM8Dk3vqF6LJfA7gtELx5gDzMYG6Oh25J8443Lk2DlgR9qztSX51F8ZnTmZ7TLHjUkeij8C2RFeaU2z9nyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jUF9w1mB4O+IrwjUm9vvAxYX5VJhVxaReOUOETG7XFM=; b=gkn0beJY+/JLLPtAnlWBMCQ/oRrMd9lq4hAtDT3em02juTTHpX9GGFFyKSyL6Hwl4XO63ED27C5uG4JSMu1zVuTAyxCzcCCOUs6guZ+VOdMnrIzRzbu28z1RVKPXVfMIXgiu7914J9Jr6JpOdgasV56TmDjwJz0HON18EAmw6FM= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3243.eurprd07.prod.outlook.com (10.170.246.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.11; Thu, 15 Aug 2019 05:34:43 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec0d:f9d3:7159:ba7]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec0d:f9d3:7159:ba7%6]) with mapi id 15.20.2178.016; Thu, 15 Aug 2019 05:34:43 +0000 From: Christer Holmberg To: Roman Shpount , Adam Roach CC: RTCWeb IETF , Justin Uberti Thread-Topic: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? Thread-Index: AQHVMfa3e75ZDw90CES618qgJ+wqxKa5mt8AgAADOwCAAAUmAIAAQMkAgAAOQACAANuCgIAAK9IAgAMRroCAAMEhgIA8nBAAgAAP4QCAAAZKgIAAAX6AgABw6WA= Date: Thu, 15 Aug 2019 05:34:42 +0000 Message-ID: References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> <7e63dd04-1b11-7118-f158-b48bda0d892d@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [79.134.118.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0be069bd-c2c5-490a-de23-08d72142468a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3243; x-ms-traffictypediagnostic: HE1PR07MB3243: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 01304918F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(366004)(346002)(39860400002)(199004)(53754006)(189003)(66476007)(446003)(66556008)(76116006)(86362001)(256004)(14444005)(66946007)(8936002)(9326002)(64756008)(11346002)(7736002)(476003)(6436002)(74316002)(66066001)(71200400001)(44832011)(186003)(71190400001)(8676002)(26005)(81166006)(486006)(81156014)(66446008)(9686003)(4326008)(54896002)(102836004)(52536014)(236005)(14454004)(6306002)(33656002)(966005)(790700001)(3846002)(55016002)(5660300002)(99286004)(25786009)(6116002)(2906002)(7696005)(53546011)(606006)(110136005)(478600001)(66574012)(6506007)(316002)(53936002)(76176011)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3243; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: RwTuXxq0ilBvLHqb38KmRMtzWkpzXLzvHeUmWuUNwC+Gp3tkADDgPWIrJFVJn2OHGCWzAy/2bOHAunT3PC1GYwX4gPwafkZSZLmIFxY0pfOtxkT9mtx32TTwmzERnBWWA3v5CNJFcrFD7UIZbC8bj9Q7wEnyEqZ2Nt0FZ674tpLSmoxraCyV5dedNSgRy+mVY6XX/CUs3JMdhM3P7XXr/epszgRB2zIhN4T3vzVED+P86cmb/yrBwS7q1ylye4uI/U6sgVNwc0VikOjMWsKV2EtvdWtFFIaLPE+gBSutPqB3oQIje8RkPn4mIJVx0rTu4ngLJqSENkxRL/pwKnAUKsXIbUZbO/GoMCOp9/dPYj8HveyjGjsxWe4Mk9Hz/CFm8ufi89VhW+ifnLQ17Jn5oIdF83o+61CxgkDtyaES5k4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB31616B7F0E2421FCE47B9C9893AC0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0be069bd-c2c5-490a-de23-08d72142468a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2019 05:34:42.8800 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4qvbi2DbdxSzMf9ty7eqWvmAhPM+Y5dCdbbjoCcLv6ZPz9zZJVguRgnGkeEZ8f0Tapf6aYL2Um2WCy26JCvYqfH0IBmUYoHs9u1lYdhJeu8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3243 Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 15 Aug 2019 05:34:50 -0000 --_000_HE1PR07MB31616B7F0E2421FCE47B9C9893AC0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWdyZWUgd2l0aCBSb21hbiwgYW5kIEkgdGhpbmsgdGhlIE1NVVNJQyB3b3VsZCBi ZSB0aGUgYmVzdCBwbGFjZSBzaW5jZSBpdCBtb3N0IGxpa2VseSB3aWxsIGhhdmUgdG8gdXBkYXRl IGFub3RoZXIgTU1VU0lDIHNwZWMuIEFsc28sIHRoZXJlIHdlcmUgcXVpdGUgYSBiaXQgb2YgZGlz Y3Vzc2lvbnMgcmVnYXJkaW5nIEZRRE4gc3VwcG9ydCBpbiBNTVVTSUMgd2hpbGUgd2Ugd2VyZSB3 b3JraW5nIG9uIGRyYWZ0LWljZS1zaXAtc2RwLCBzbyBpbiBteSBvcGluaW9uIGEgcHJvcGVyIFdH IGlzIHRoZSBiZXN0IHBsYWNlIHRvIHdvcmsgb24gdGhlIGRyYWZ0Lg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCg0KTMOkaGV0dMOkasOkOiBydGN3ZWIgPHJ0Y3dlYi1ib3VuY2VzQGlldGYu b3JnPiBQdW9sZXN0YSBSb21hbiBTaHBvdW50DQpMw6RoZXRldHR5OiB0b3JzdGFpIDE1LiBlbG9r dXV0YSAyMDE5IDEuNDYNClZhc3RhYW5vdHRhamE6IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5j b20+DQpLb3BpbzogUlRDV2ViIElFVEYgPHJ0Y3dlYkBpZXRmLm9yZz47IEp1c3RpbiBVYmVydGkg PGp1YmVydGk9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPg0KQWloZTogUmU6IFtydGN3ZWJd IElzIHJ0Y3dlYiB0aGUgcmlnaHQgcGxhY2UgZm9yIGRyYWZ0LWlldGYtcnRjd2ViLW1kbnMtaWNl LWNhbmRpZGF0ZXM/DQoNCkp1c3Qgd2FudCB0byByZW1pbmQgZXZlcnlvbmUgdGhhdCBhIG5ldyBk cmFmdCB3aWxsIG5lZWQgdG8gYmUgd3JpdHRlbiB0byB1cGRhdGUgaWNlLXNpcC1zZHAgdG8gZW5h YmxlIHNlbmRpbmcgRlFETiBpbiBJQ0UgY2FuZGlkYXRlcyBiZWZvcmUgbWRucy1pY2UtY2FuZGlk YXRlIGNhbiBiZSByZWxlYXNlZC4gSSB3b3VsZCBhc3N1bWUgaXQgd291bGQgbmVlZCB0byBoYXBw ZW4gaW4gbW11c2ljLg0KDQpBbHNvLCBtZG5zLWljZS1jYW5kaWRhdGUgaXMgbm90IHJlYWxseSBy dGN3ZWIgc3BlY2lmaWMuIElQIGFkZHJlc3MgcHJpdmFjeSBjb25jZXJucyBhZGRyZXNzZWQgdGhp cyBkcmFmdCBhcHBseSB0byBhbnkgcGVlci10by1wZWVyIGNvbW11bmljYXRpb24gcHJvdG9jb2wg dGhhdCB1c2VzIElDRS4NCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KDQpPbiBXZWQs IEF1ZyAxNCwgMjAxOSBhdCA2OjQwIFBNIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFp bHRvOmFkYW1Abm9zdHJ1bS5jb20+PiB3cm90ZToNCkp1c3RpbiBpcyBjb3JyZWN0IHJlZ2FyZGlu ZyB0aGUgY3VycmVudCBwbGFuLg0KDQovYQ0KDQpPbiA4LzE0LzE5IDU6MTggUE0sIEp1c3RpbiBV YmVydGkgd3JvdGU6DQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZHJhZnQtaWV0Zi1ydGN3ZWIt bWRucy1pY2UtY2FuZGlkYXRlcyBpcyBnb2luZyB0byBiZSBBRCBzcG9uc29yZWQuDQoNCk9uIFdl ZCwgQXVnIDE0LCAyMDE5IGF0IDI6MjEgUE0gUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5j b208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQpIaSBBbGwsDQoNClNpbmNlIFJU Q1dFQiBpcyBjbG9zZWQsIEkgYW0gZ29pbmcgdG8gYXNrIG9uY2UgYWdhaW46IFNob3VsZCB3ZSBt b3ZlIGRyYWZ0LWlldGYtcnRjd2ViLW1kbnMtaWNlLWNhbmRpZGF0ZXMgdG8gbW11c2ljPw0KDQpJ IGtub3cgcGVvcGxlIGFyZSB1bmhhcHB5IHdpdGggbW11c2ljIGRyYWZ0IGRldmVsb3BtZW50IHNw ZWVkLCBidXQgaWYgZW5vdWdoIHBlb3BsZSBwYXJ0aWNpcGF0ZSwgd2Ugc2hvdWxkIGJlIGFibGUg dG8gY29tcGxldGUgbWRucyBkcmFmdCBxdWlja2x5IGFuZCBwb3RlbnRpYWxseSBkZXZlbG9wIGFu IGFkZGl0aW9uYWwgZHJhZnQgd2hpY2ggd2lsbCBjbGFyaWZ5IGdlbmVyaWMgRlFETiBjYW5kaWRh dGUgcHJvY2Vzc2luZyBwcm9jZWR1cmVzLg0KDQpUaGFuayBZb3UsDQpfX19fX19fX19fX19fDQpS b21hbiBTaHBvdW50DQoNCg0KT24gU3VuLCBKdWwgNywgMjAxOSBhdCAzOjQ3IEFNIEhhcmFsZCBB bHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQu bm8+PiB3cm90ZToNCk9uIDcvNi8xOSAxMDoxNSBQTSwgUm9tYW4gU2hwb3VudCB3cm90ZToNCg0K R2l2ZW4gbW11c2ljJ3MgdHJhZGl0aW9uYWwgcHJvY2Vzc2luZyBzcGVlZCwgSSBhbSBub3Qgc3Vy ZSB0aGVyZSdzIGFueQ0KcG9pbnQgaW4gZm9ybWFsbHkgbW92aW5nIHRoZSBkb2N1bWVudCBhdCB0 aGlzIHBvaW50Lg0KDQpJdCBpcyBlc3BlY2lhbGx5IHNsb3cgd2hlbiBub25lIG9mIHRoZSBwZW9w bGUgaW50ZXJlc3RlZCBpbiB0aGUgc3BlY2lmaWMgZmVhdHVyZSAoRlFETiBpbiBJQ0UgY2FuZGlk YXRlcykgcGFydGljaXBhdGUgaW4gdGhlIGRpc2N1c3Npb24uIFNvIGZhciB0aGlzIGxvb2tzIGxp a2UgdGhpcyBmZWF0dXJlIGlzIGdvaW5nIHRvIGJlIHNoaXBwZWQgcmVnYXJkbGVzcyBvZiB3aGF0 IGFueWJvZHkgdGhpbmtzIGFib3V0IGl0IGFuZCB3aXRob3V0IGV2ZW4gYXR0ZW1wdGluZyB0byBk aXNjdXNzIGl0IGluIHRoZSBncm91cCB3aGljaCBpcyByZXNwb25zaWJsZSBmb3IgdGhpcyBmdW5j dGlvbmFsaXR5Lg0KDQpNeSBmYXZvcml0ZSBleGFtcGxlcyBhcmUgLW1zaWQgKGluaXRpYWwgdmVy c2lvbiBNYXkgMjAxMiwgSUVTRyBldmFsdWF0aW9uIEp1bmUgMjAxNik7IC1zZHAtc2ltdWxjYXN0 IChpbml0aWFsIHZlcnNpb24gQXByaWwgMjAxNSwgSUVTRyBldmFsdWF0aW9uIE1heSAyMDE4KTsg LWJ1bmRsZS1uZWdvdGlhdGlvbiAoaW5pdGlhbCB2ZXJzaW9uIE9jdG9iZXIgMjAxMSwgSUVTRyBl dmFsdWF0aW9uIEZlYnJ1YXJ5IDIwMTgpLg0KDQpFYWNoIG9mIHRoZXNlIGhhcyBpdHMgb3duIGhp c3RvcnksIGJ1dCB3aGVuIGEgZ3JvdXAgaXMgY2FwYWJsZSBvZiBkaXNjdXNzaW5nIGEgZHJhZnQg Zm9yIHNldmVuIHllYXJzIGJlZm9yZSBpdCBpcyBJRVNHLXJlYWR5LCBJIHF1ZXN0aW9uIHRoZSBl ZmZlY3RpZW5lc3Mgb2YgbW92aW5nIGRyYWZ0cyBpbnRvIHRoYXQgZ3JvdXAuDQoNCg0KQmVzdCBS ZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQoNCg0KDQotLQ0KDQpTdXJ2 ZWlsbGFuY2UgaXMgcGVydmFzaXZlLiBHbyBEYXJrLg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRm Lm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWINCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpydGN3ZWIgbWFpbGluZyBsaXN0DQoNCnJ0Y3dlYkBpZXRmLm9yZzxt YWlsdG86cnRjd2ViQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0KDQoNCg== --_000_HE1PR07MB31616B7F0E2421FCE47B9C9893AC0HE1PR07MB3161eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwtZXNpbXVvdG9pbHR1 IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTC1lc2ltdW90 b2lsdHVDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MLWVzaW11b3RvaWx0dSBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6SFRNTC1lc2ltdW90b2lsdHU7 DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1HQjt9DQpzcGFuLlNoa3Bvc3RpdHl5bGkyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkkgYWdyZWUgd2l0aCBSb21hbiwgYW5kIEkgdGhpbmsgdGhlIE1NVVNJQyB3b3VsZCBi ZSB0aGUgYmVzdCBwbGFjZSBzaW5jZSBpdCBtb3N0IGxpa2VseSB3aWxsIGhhdmUgdG8gdXBkYXRl IGFub3RoZXIgTU1VU0lDIHNwZWMuIEFsc28sIHRoZXJlIHdlcmUgcXVpdGUgYSBiaXQgb2YgZGlz Y3Vzc2lvbnMgcmVnYXJkaW5nIEZRRE4gc3VwcG9ydA0KIGluIE1NVVNJQyB3aGlsZSB3ZSB3ZXJl IHdvcmtpbmcgb24gZHJhZnQtaWNlLXNpcC1zZHAsIHNvIGluIG15IG9waW5pb24gYSBwcm9wZXIg V0cgaXMgdGhlIGJlc3QgcGxhY2UgdG8gd29yayBvbiB0aGUgZHJhZnQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRkkiPkzDpGhldHTDpGrDpDo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZJIj4gcnRj d2ViICZsdDtydGN3ZWItYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPlB1b2xlc3RhIDwvYj5Sb21h biBTaHBvdW50PGJyPg0KPGI+TMOkaGV0ZXR0eTo8L2I+IHRvcnN0YWkgMTUuIGVsb2t1dXRhIDIw MTkgMS40Njxicj4NCjxiPlZhc3RhYW5vdHRhamE6PC9iPiBBZGFtIFJvYWNoICZsdDthZGFtQG5v c3RydW0uY29tJmd0Ozxicj4NCjxiPktvcGlvOjwvYj4gUlRDV2ViIElFVEYgJmx0O3J0Y3dlYkBp ZXRmLm9yZyZndDs7IEp1c3RpbiBVYmVydGkgJmx0O2p1YmVydGk9NDBnb29nbGUuY29tQGRtYXJj LmlldGYub3JnJmd0Ozxicj4NCjxiPkFpaGU6PC9iPiBSZTogW3J0Y3dlYl0gSXMgcnRjd2ViIHRo ZSByaWdodCBwbGFjZSBmb3IgZHJhZnQtaWV0Zi1ydGN3ZWItbWRucy1pY2UtY2FuZGlkYXRlcz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IHdhbnQgdG8gcmVtaW5k IGV2ZXJ5b25lIHRoYXQgYSBuZXcgZHJhZnQgd2lsbCBuZWVkIHRvIGJlIHdyaXR0ZW4gdG8gdXBk YXRlIGljZS1zaXAtc2RwIHRvIGVuYWJsZSBzZW5kaW5nIEZRRE4gaW4gSUNFIGNhbmRpZGF0ZXMg YmVmb3JlIG1kbnMtaWNlLWNhbmRpZGF0ZSBjYW4gYmUgcmVsZWFzZWQuIEkgd291bGQgYXNzdW1l IGl0IHdvdWxkIG5lZWQgdG8gaGFwcGVuIGluIG1tdXNpYy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIG1kbnMtaWNlLWNhbmRpZGF0ZSBpcyBub3Qg cmVhbGx5IHJ0Y3dlYiBzcGVjaWZpYy4gSVAgYWRkcmVzcyBwcml2YWN5IGNvbmNlcm5zIGFkZHJl c3NlZCB0aGlzIGRyYWZ0IGFwcGx5IHRvIGFueSBwZWVyLXRvLXBlZXIgY29tbXVuaWNhdGlvbiBw cm90b2NvbCB0aGF0IHVzZXMgSUNFLjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9t YW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyAxNCwgMjAxOSBhdCA2OjQwIFBNIEFkYW0gUm9hY2ggJmx0 OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIj5hZGFtQG5vc3RydW0uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3RpbiBpcyBjb3JyZWN0IHJlZ2FyZGluZyB0aGUg Y3VycmVudCBwbGFuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4vYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiA4LzE0LzE5IDU6MTggUE0sIEp1c3RpbiBVYmVydGkgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCBkcmFmdC1pZXRmLXJ0Y3dlYi1tZG5zLWljZS1jYW5kaWRhdGVzIGlz IGdvaW5nIHRvIGJlIEFEIHNwb25zb3JlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDE0LCAyMDE5IGF0IDI6MjEgUE0gUm9tYW4gU2hw b3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFu ayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQWxsLCA8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlIFJUQ1dFQiBpcyBjbG9zZWQsIEkg YW0gZ29pbmcgdG8gYXNrIG9uY2UgYWdhaW46IFNob3VsZCB3ZSBtb3ZlJm5ic3A7ZHJhZnQtaWV0 Zi1ydGN3ZWItbWRucy1pY2UtY2FuZGlkYXRlcyB0byBtbXVzaWM/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkga25vdyBwZW9wbGUgYXJlIHVu aGFwcHkgd2l0aCBtbXVzaWMgZHJhZnQgZGV2ZWxvcG1lbnQgc3BlZWQsIGJ1dCBpZiBlbm91Z2gg cGVvcGxlIHBhcnRpY2lwYXRlLCB3ZSBzaG91bGQgYmUgYWJsZSB0byBjb21wbGV0ZSBtZG5zIGRy YWZ0IHF1aWNrbHkgYW5kIHBvdGVudGlhbGx5IGRldmVsb3AgYW4gYWRkaXRpb25hbCBkcmFmdCB3 aGljaCB3aWxsIGNsYXJpZnkgZ2VuZXJpYyBGUUROIGNhbmRpZGF0ZSBwcm9jZXNzaW5nDQogcHJv Y2VkdXJlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmsgWW91LDxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hw b3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBTdW4sIEp1bCA3LCAyMDE5IGF0IDM6NDcgQU0gSGFyYWxkIEFsdmVzdHJhbmQgJmx0 OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyIgdGFyZ2V0PSJfYmxhbmsiPmhh cmFsZEBhbHZlc3RyYW5kLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0O21hcmdpbjowLi44ZXgiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiA3LzYvMTkgMTA6MTUgUE0sIFJvbWFuIFNocG91bnQgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZl biBtbXVzaWMncyB0cmFkaXRpb25hbCBwcm9jZXNzaW5nIHNwZWVkLCBJIGFtIG5vdCBzdXJlIHRo ZXJlJ3MgYW55PGJyPg0KcG9pbnQgaW4gZm9ybWFsbHkgbW92aW5nIHRoZSBkb2N1bWVudCBhdCB0 aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXQgaXMgZXNwZWNpYWxseSBzbG93IHdoZW4gbm9uZSBvZiB0aGUgcGVv cGxlIGludGVyZXN0ZWQgaW4gdGhlIHNwZWNpZmljIGZlYXR1cmUgKEZRRE4gaW4gSUNFIGNhbmRp ZGF0ZXMpIHBhcnRpY2lwYXRlIGluIHRoZSBkaXNjdXNzaW9uLiBTbyBmYXIgdGhpcyBsb29rcyBs aWtlIHRoaXMgZmVhdHVyZSBpcyBnb2luZyB0byBiZSBzaGlwcGVkIHJlZ2FyZGxlc3Mgb2Ygd2hh dCBhbnlib2R5IHRoaW5rcyBhYm91dA0KIGl0IGFuZCB3aXRob3V0IGV2ZW4gYXR0ZW1wdGluZyB0 byBkaXNjdXNzIGl0IGluIHRoZSBncm91cCB3aGljaCBpcyByZXNwb25zaWJsZSBmb3IgdGhpcyBm dW5jdGlvbmFsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPHA+TXkgZmF2b3JpdGUgZXhhbXBsZXMgYXJlIC1tc2lkIChpbml0aWFsIHZl cnNpb24gTWF5IDIwMTIsIElFU0cgZXZhbHVhdGlvbiBKdW5lIDIwMTYpOyAtc2RwLXNpbXVsY2Fz dCAoaW5pdGlhbCB2ZXJzaW9uIEFwcmlsIDIwMTUsIElFU0cgZXZhbHVhdGlvbiBNYXkgMjAxOCk7 IC1idW5kbGUtbmVnb3RpYXRpb24gKGluaXRpYWwgdmVyc2lvbiBPY3RvYmVyIDIwMTEsIElFU0cg ZXZhbHVhdGlvbiBGZWJydWFyeSAyMDE4KS48bzpwPjwvbzpwPjwvcD4NCjxwPkVhY2ggb2YgdGhl c2UgaGFzIGl0cyBvd24gaGlzdG9yeSwgYnV0IHdoZW4gYSBncm91cCBpcyBjYXBhYmxlIG9mIGRp c2N1c3NpbmcgYSBkcmFmdCBmb3Igc2V2ZW4geWVhcnMgYmVmb3JlIGl0IGlzIElFU0ctcmVhZHks IEkgcXVlc3Rpb24gdGhlIGVmZmVjdGllbmVzcyBvZiBtb3ZpbmcgZHJhZnRzIGludG8gdGhhdCBn cm91cC48bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpS b21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4N CjxwcmU+U3VydmVpbGxhbmNlIGlzIHBlcnZhc2l2ZS4gR28gRGFyay48bzpwPjwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2Vi IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+cnRjd2ViIG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48 bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_HE1PR07MB31616B7F0E2421FCE47B9C9893AC0HE1PR07MB3161eurp_-- From nobody Thu Aug 15 11:20:40 2019 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 6B074120F14 for ; Wed, 14 Aug 2019 15:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 PrK2SRMZD45F for ; Wed, 14 Aug 2019 15:18:57 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 411E41208E3 for ; Wed, 14 Aug 2019 15:18:57 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id r21so446450qke.2 for ; Wed, 14 Aug 2019 15:18:57 -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=oe0TUsc35liOTqdZP8WRx3/wnmMvwXk847a8LDDJviU=; b=ArPSAREefRYlktw9Zz7Z/CEjqQZh+VNlYi5O+GseMbrqXHUPXlSj5vXvQcB8O5ylVr AxiweqKdCvq6v5KwH7S+eSyZCaeRERGYFw4iImj1TxiEfxNScUu//0L49otUkJplZ3G1 LQtnlIuOCX+8gbwFuyx1XYwmdAOCzlrNRPu4ZQWFjkh+2+v+1hSCBXRUOcbZL96/Z9rz lca93l630LPMkWHdeV/7tzK4anMVqX9L6vUCwq/kPm76PpqKz8E8sGZNhGvd0jwEvm/l 3zwfRgyQdaNqE9SGcwrdyHmNElWNz7tV4tgyEM3b0sCeKX5ZXqB6SX/XrOdmGgPgjOUX AU7A== 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=oe0TUsc35liOTqdZP8WRx3/wnmMvwXk847a8LDDJviU=; b=DqisJJSx32yQiriJXKtVHu0Bp89DYfxlUbiHV3tS41cbz5xa90PQiXoqAKGIHUq2kG ECW6p6ioH+uHCLJtVc9wC6MbegwArnaux/x61TUc7a68W640C0O/MEYDKn+CvAcqLVNn lvuggznc284NJjY3wlhzMGNpTdN60Jx0e6Ca4XBmOARt4auz159XsQaJhOdb5SBIpP96 GPeb/j44bVLkmnwf4aWWt2snesKoByKaj332oXGqAcmMdIojLJ2bfIaVnsMwiQN6f29j WgO19x4OToL0bmHC44cXewAVA2oVyguayS3UwJQq22xkM7kgUWCoQwOjGsI7mW394Qw5 6T+Q== X-Gm-Message-State: APjAAAWwaJas4shIIRm+j3e/J/1rbeOnM6AMPB/6x1JMBcNKHR/H8OGw XJbWRdCMirHxIXoRdn/XFUIlGO5NpVmF3Z6kyWg= X-Google-Smtp-Source: APXvYqx+jxxDVz9+E+x5s+AxzM1DFEN/u/Si7sMG2Qd/kWjhVi4Kwrj89mvkeqJl5QKNvNMb90Occ0CTZqvIX8Is+Io= X-Received: by 2002:a37:be41:: with SMTP id o62mr1462160qkf.356.1565821136350; Wed, 14 Aug 2019 15:18:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Silvia Pfeiffer Date: Thu, 15 Aug 2019 08:18:45 +1000 Message-ID: To: Ted Hardie Cc: rtcweb@ietf.org, Harald Alvestrand , Gonzalo Camarillo , Magnus Westerlund , Mary Barnes , Sean Turner , Cullen Jennings , Alissa Cooper , Adam Roach Content-Type: multipart/alternative; boundary="0000000000009d347505901b24e5" Archived-At: X-Mailman-Approved-At: Thu, 15 Aug 2019 11:20:38 -0700 Subject: Re: [rtcweb] The late, great RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 14 Aug 2019 22:19:00 -0000 --0000000000009d347505901b24e5 Content-Type: text/plain; charset="UTF-8" Mission success! Congratulations everyone!! On Thu., 15 Aug. 2019, 5:12 am Ted Hardie, wrote: > For those of you who like to flip to the end of a book: with the entry of > the final dependencies of its core work into the RFC Editor queue, the > working group is closing. The mailing list will remain open for > discussion, and any trailing documents will be processed by Adam as AD > sponsored or headed to DISPATCH. > > For those of you who wish to take a journey, open your books to IETF 80, > in Prague ; it's late > March and Spring is in the air. A large and plucky band of folks are > trying to work out if it is possible to have real time communications in a > browser without any plugins. The resulting work will require protocol > changes, new APIs, and a new level of cooperation between the IETF and the > W3C. The outlook is optimistic; the IESG agrees to a mailing list on April > 4, 2011 and to make the effort a working group on May 3rd. > > Our first meeting as a working group was IETF 81 > : The rooms were large, > the energy palpable, and the optimism at a quick and decisive effort had > resulted in a charter with milestones like this: > > Goals and Milestones: > > Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C > > Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to W3C > > Sep 2011 Architecture and Security, Privacy, and Threat Model document(s) > to IESG as Informational > > Sep 2011 Use cases, Scenarios, and Requirements for RTCWeb document sent > to IESG as Informational > > Dec 2011 RTCWeb protocol profiles and Media format specification(s) to > IESG as PS > > Dec 2011 Information elements and events APIs Input to W3C > > Apr 2012 API to Protocol mapping document submitted to the IESG as > Informational (if needed) > > Ladies and gentleman, we are a bit late. > > During the time this working group was active, we went through multiple > ADs: Gonzalo was succeeded by Alissa and then by Adam. The Area we were > in, RAI, was merged with APPS to create ART. Magnus, one of the original > WG chairs, had a baby and was succeeded by Sean, who then had a baby > (Actually, make that two babies in both cases). Cullen was eventually > poached by his management to serve as CTO of Webex. > > The group was also prolific. My personal archive for the mailing list > shows just over 9000 messages, (though this is slightly inflated by my > putting chair messages in there as well.) The cluster of documents that > is the output of the work in RTCWEB and in the working groups on whom we > had dependencies has become legendary: cluster 238 gave rise to both some > extraordinary dwell times (the data protocol and channel drafts are at 1679 > days, more than four and half years) and some RFC editor innovations (the > creation of a cluster mailing list, so that AUTH48 changes are coordinated > across groups). > > While the working group tussled over interoperability with non-browser > systems and then on the implications of that decision for codecs, we lost > some time. We appear, however, to have made up for it: WebRTC is > available in well over a billion applications or endpoints. By the simple > metrics of rough consensus and running code, it is a runaway success. > > On behalf of all the chairs and area directors who were part of the > journey, for your contributions to that success, whether as document > author, minute taker, jabber scribe, interim host, comment maker or poser > of questions, > > many thanks, > > Ted Hardie > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000009d347505901b24e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mission success!
Congratulations everyon= e!!


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu., 15 Aug. 2019, 5:12 am Ted Har= die, <ted.ietf@gmail.com> w= rote:
For tho= se of you who like to flip to the end of a book:=C2=A0 with the=20 entry of the final dependencies of its core work into the RFC Editor=20 queue, the working group is closing.=C2=A0 The mailing list will remain ope= n=20 for discussion, and any trailing documents will be processed by Adam as=20 AD sponsored or headed to DISPATCH.=C2=A0

For= those of you who wish to take a journey, open your books to IETF 80, in Prague; it's late March and Spring is in the air.=C2=A0 A large and plucky ban= d of=20 folks are trying to work out if it is possible to have real time=20 communications in a browser without any plugins.=C2=A0 The resulting work= =20 will require protocol changes, new APIs, and a new level of cooperation=20 between the IETF and the W3C.=C2=A0 The outlook is optimistic; the IESG agr= ees to a mailing list on April 4, 2011 and to make the effort a working group=20 on May 3rd.=C2=A0

Our first meeting as a work= ing group was=C2=A0 IETF 81:=C2=A0 The rooms were large, the energy palpable, and the optimism at a quick and= =20 decisive effort had resulted in a charter with milestones like this:
<= div>
Goals and Milestones:

Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C

Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to=C2= =A0 W3C

Sep 2011 Architecture and Security, Privacy, and Threat Model document(s) t= o IESG as Informational

Sep 2011 Use cases, Scenarios, and Requirements for RTCWeb document sent to= IESG as Informational

Dec 2011 RTCWeb protocol profiles and Media format specification(s) to IESG= as PS

Dec 2011 Information elements and events APIs Input to W3C

Apr 2012 API to Protocol mapping document submitted to the IESG as Informat= ional (if needed)

Ladies and gentleman, we ar= e a bit late.=C2=A0

During the time this working group was active, we went through multiple ADs:=20 Gonzalo was succeeded by Alissa and then by Adam.=C2=A0 The Area we were in= , RAI, was merged with APPS to create ART.=C2=A0 Magnus, one of the origina= l=20 WG chairs, had a baby and was succeeded by Sean, who then had a baby=20 (Actually, make that two babies in both cases).=C2=A0 Cullen was eventually= =20 poached by his management to serve as CTO of Webex.=C2=A0=C2=A0
<= div>
The group was also prolific.=C2=A0 My personal archive for the mailing list=20 shows just over 9000 messages, (though this is slightly inflated by my=20 putting chair messages in there as well.)=C2=A0=C2=A0 The cluster of docume= nts=20 that is the output of the work in RTCWEB and in the working groups on=20 whom we had dependencies has become legendary: cluster 238 gave rise to=20 both some extraordinary dwell times (the data protocol and channel=20 drafts are at 1679 days, more than four and half years) and some RFC=20 editor innovations (the creation of a cluster mailing list, so that=20 AUTH48 changes are coordinated across groups).

While the working group tussled over interoperability with non-browser=20 systems and then on the implications of that decision for codecs, we=20 lost some time.=C2=A0 We appear, however,=C2=A0 to have made up for it:=C2= =A0 WebRTC is=20 available in well over a billion applications or endpoints.=C2=A0 By the=20 simple metrics of rough consensus and running code, it is a runaway=20 success.

On behalf of all the chairs and area=20 directors who were part of the journey, for your contributions to that=20 success, whether as document author, minute taker, jabber scribe,=20 interim host, comment maker or poser of questions,=C2=A0
many thanks,

Ted Hardie
_______________________________________________
rtcweb mailing list
rtc= web@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb<= /a>
--0000000000009d347505901b24e5-- From nobody Tue Aug 27 02:50:50 2019 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 34EE31200FD for ; Tue, 27 Aug 2019 02:50:48 -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_HELO_NONE=0.001, 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 accD6sHcdr0z for ; Tue, 27 Aug 2019 02:50:46 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 367AC1200F1 for ; Tue, 27 Aug 2019 02:50:46 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id o9so44838628iom.3 for ; Tue, 27 Aug 2019 02:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=iAET5LWDLm90Xr3yeD0a5mNWCfkEOR2WvvIErvskfqE=; b=MsIuctIFCOlDnfrRdAaEmLbsqez3silSZHnUux8GzpRcnOFa8HEwiUYzrQXhgxJPU7 FvJpFUb3aH2RXH1a0efUAVP6RqdJ6qNWCNARuWMkwSAqt2t98RRfB5nrPFmyuRteHJc/ 0mJFr/TliJu6vqtj8JELHlF7TNqJOS2p1pL/9i5XpeiJ1ZIzYaAHj6+BO2M6qCIEQGgH dGrYEIztArcbEQx1DkP7h3SewFIMg/Te/ciKX6/zhJSw2h0gByCeqItSZdAM6KquCdZu bXuYgKRhgmMfYDbCeHJKAozy8XzlIaQPu7Qo8g7yiFd9p+IwpyAaTHCyLxmJTwniIhcI zMqw== 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:cc; bh=iAET5LWDLm90Xr3yeD0a5mNWCfkEOR2WvvIErvskfqE=; b=tAXFE4hfWoER+4Q0QiVziWtD6+jK/k+nYcm2HERUvnSJG4B1xG4tr7GgSgRWKclO+T FbvjnCoF3UcYg7haGFXFagkW2siYT72aIgcmpVGftSh3TiN1fOpuQomYwB7kDeinBTWQ vktldQQjZupOsdXYVUWZERuw9ZTfVSYyMVrTX++WqhgLl0ju9wZbl/bnYNTSpmK3vsrU +YKstRsVlejRafp5GYRVHlg8oleFjWe2hRLWAqj3AFx+qb8ASKp/5FYQD5a3bc3NdoqW YpUTNQFKwiY2ZBmzaDr19uYW4+hJBkJwzmXGns4Qppfzcgt/3h/wF5aZSuKUi2QNiRQJ sj+Q== X-Gm-Message-State: APjAAAVU8xwJVHFSR0ZbBNyMdy5oZOvuN4925WTm9TkV8BnbRZhv3Z9+ K0L/VHsfSzYb0KGBxxor4vjtkubbtRcoj+DWabCM5uNz X-Google-Smtp-Source: APXvYqydMztjgQFZyH+tx9eiraJwrLoGfKzClZZWsOh8/Cd5QJocO96S89COQb88IQ4TQS64foJhNJsfYZNx3BVWtwY= X-Received: by 2002:a02:37c6:: with SMTP id r189mr10254071jar.118.1566899445180; Tue, 27 Aug 2019 02:50:45 -0700 (PDT) MIME-Version: 1.0 From: Vikas Jayaprakash Date: Tue, 27 Aug 2019 18:50:40 +0900 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="000000000000d431d505911634a7" Archived-At: Subject: [rtcweb] Optimum SDP Parameters for Video Call (OTT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 27 Aug 2019 09:50:48 -0000 --000000000000d431d505911634a7 Content-Type: text/plain; charset="UTF-8" Hi Expert Group, I have been following this group sometime and have a questions. Your inputs are highly appreciated. I am here focussed and interested to know most optimum SDP values used for Video call initiated by Web RTC client towards WebRTC Gateway in a RCS network. 1. Is RFC 7742 the right standard to refer to determine standard values for VP8/H264 or there are latest RFCs that dictates the optimum values? 2. Are there any more factors that decide optimum values part from below: 1. Bandwidth Information 2. Packetization 3. fmtp/rtcp-rsize, mux/maxptime/ 3. Any offer/answer SDP examples that are currently run on Google WRTC client would be very helpful 4. Any feedback on End to End QoS for Video call over RCS network. Thanks, Vikas --000000000000d431d505911634a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Expert Group,

I have been following = this group sometime and have a questions.
Your inputs are highly = appreciated.

I am here focussed and interested to = know most optimum SDP values used for Video call initiated by Web RTC clien= t towards WebRTC Gateway in a RCS network.
  1. Is=C2=A0 RFC 7= 742 the right standard to refer to determine standard values for VP8/H264 o= r there are latest RFCs that dictates the optimum values?
  2. Are there= any more factors that decide optimum values part from below:
    1. = =C2=A0Bandwidth Information
    2. =C2=A0Packetization
    3. fmtp/rtcp-r= size, mux/maxptime/
  3. Any offer/answer SDP examples that are cur= rently run on Google WRTC client would be very helpful
  4. Any feedback= on End to End QoS for Video call over RCS network.
Thanks,
Vikas
--000000000000d431d505911634a7--