From nobody Mon Oct 1 13:28:09 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9E130E26 for ; Mon, 1 Oct 2018 13:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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_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 UmnSYXdkzUqE for ; Mon, 1 Oct 2018 13:28:04 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 89F99130E0A for ; Mon, 1 Oct 2018 13:28:04 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id p64-v6so198557itp.0 for ; Mon, 01 Oct 2018 13:28:04 -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=a12CoQJJgwlBES8h6U10wourkTosGA/q2YOqfyKmOC8=; b=o1HpctyDkRVuWXNt0SdK96+urJfALR45mVsHMYHX92Y8huY2vhL9MYAPRhheWzSCyI 16mEjmqsmr2y9dWzjoMjp9eJnxUGKPPvJx5e9FLjSHUWicVKlqeRARiwFV135yXj4HDh xURxDJq7bUGYRJdjCLHkIK5Kp+fghrwIgvmh8FfR0D8G9r8Dj+wnPXBluA2DV+sEI+FD HSUZAXQP7nQuX0Q6QvMqpga/5VRf9lvdEbQeg4kljH8qxsZ29lpCJGuJnlY99FWM3MGr V7NWj/oZTspthvNe/LRCdYWUoUdULkSPD0NTZRoS1IyjY5urTfvvgA0esHQNgvaw73M9 oJfw== 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=a12CoQJJgwlBES8h6U10wourkTosGA/q2YOqfyKmOC8=; b=RrOj3JfrJjM0flt+0go9mwNDXtfRb3npzChLNblgmRwZGAjcq1SYn2E0L8WOZVP7R9 CPtuMKBT8p/kFdTD5C/gx8XlikeWSm4Yylql7YSOzcuBlvYm7xbeSx9dAFJ3wlyfDjyl hbNaASG4+TClq6pUl+IEeZwBmaGL2BvhJoFpJsh57tIqWbrgQyeQKT3q5tiAIwqIFUAq rEufeN2nLLE+z1uTSENSXo61e+X4Qc7Q4VTzGDEf/8c5uoYYgMsWYsnkm/YosIoWXpBK ar//KKVWUQHQk9hiZ9z8scv7RPEMeluh8rsBmRJEoYiJnbNhzH8jEAf/iHlJp2Xm9PsJ DfAg== X-Gm-Message-State: ABuFfohcQjSWPmtVBelaqPYTVDaDuc8rJsFmysWBwACPwCTW/Eth3L1f eA5+ryE6zQVo/XZLATsAWHuTtUbwnMky8AP9R8/twA== X-Google-Smtp-Source: ACcGV61tZ1EgFuh/Xch5KiOSloGikFrz6e8EeOHXGNpCYJp4F8ziJgd/Azx2CajRenX3oLwWsh3iuHcZ7Wf+OYfDN3Q= X-Received: by 2002:a24:d1c5:: with SMTP id w188-v6mr10488896itg.99.1538425683533; Mon, 01 Oct 2018 13:28:03 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> In-Reply-To: From: Justin Uberti Date: Mon, 1 Oct 2018 13:27:50 -0700 Message-ID: To: Adam Roach Cc: Peter Thatcher , RTCWeb IETF , Cullen Jennings , Christer Holmberg , "Heather Flanagan (RFC Series Editor)" , ice@ietf.org Content-Type: multipart/alternative; boundary="00000000000061e47e057730a41d" Archived-At: Subject: Re: [Ice] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:28:07 -0000 --00000000000061e47e057730a41d Content-Type: text/plain; charset="UTF-8" [dropping some DLs] I think this is probably a day of work, but will probably take 2 weeks to author and get approval for. If we go down this path, I would also suggest taking the two pending PRs in JSEP, which will also impact the examples. https://github.com/rtcweb-wg/jsep/pull/849 https://github.com/rtcweb-wg/jsep/pull/850 On Mon, Oct 1, 2018 at 1:23 PM Justin Uberti wrote: > I think this is probably a day of work, but will probably take 2 weeks to > author and get approval for. > > If we go down this path, I would also suggest taking the two pending PRs > in JSEP, which will also impact the examples. > https://github.com/rtcweb-wg/jsep/pull/849 > https://github.com/rtcweb-wg/jsep/pull/850 > > On Mon, Oct 1, 2018 at 12:17 PM Adam Roach wrote: > >> On 9/27/18 6:20 PM, Justin Uberti wrote: >> > I agree with Peter. Chrome's implementation is already closer to 8445 >> > than 5245, so I don't see any issues associated with snapping this >> > cluster to 8445 (aside from the work involved). >> > >> > On that topic, note that JSEP will need a few more changes than just >> > the addition of the 8445 reference and note; the examples will have to >> > be updated, as will the logic regarding generation of offers and >> > answers and their parsing (to deal with the new ice-option). These >> > changes will be modest but probably will need to be done by the authors. >> >> >> If I read what you're saying correctly, it sounds like you're talking >> about changes that are significant enough that we'll have to put JSEP >> through IETF last call and through the IESG again. That being the case, >> and the rest of the cluster being so close to done, I'd really prefer to >> see this done very soon, if such changes are required. When do you >> believe such an update could be available? >> >> I've copied the RFC Series Editor on this note for her awareness. >> >> /a >> >> --00000000000061e47e057730a41d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[dropping some DLs]

I think this = is probably a day of work, but will probably take 2 weeks to author and get= approval for.

If we go down this path, I would also sug= gest taking the two pending PRs in JSEP, which will also impact the example= s.
http= s://github.com/rtcweb-wg/jsep/pull/850
<= br class=3D"gmail-Apple-interchange-newline">

On Mon, Oct 1, 2018 at 1:23 PM Justin U= berti <juberti@google.com> = wrote:
I think this is probably a day of w= ork, but will probably take 2 weeks to author and get approval for.
If we go down this path, I would also suggest taking the two pe= nding PRs in JSEP, which will also impact the examples.

On Mon, Oct 1, 2018 at 12:17 PM Adam Roach <= adam@nostrum.com&= gt; wrote:
On 9/27/18 6:20 PM, Just= in Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8= 445
> than 5245, so I don't see any issues associated with snapping this=
> cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just <= br> > the addition of the 8445 reference and note; the examples will have to=
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the author= s.


If I read what you're saying correctly, it sounds like you're talki= ng
about changes that are significant enough that we'll have to put JSEP <= br> through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer t= o
see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

--00000000000061e47e057730a41d-- From nobody Tue Oct 2 09:47:04 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3912785F; Tue, 2 Oct 2018 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYNMxXTJmmoE; Tue, 2 Oct 2018 09:46:45 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A83128D68; Tue, 2 Oct 2018 09:46:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E3BC11D06E0; Tue, 2 Oct 2018 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diQf7_ynoKzC; Tue, 2 Oct 2018 09:46:30 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [108.177.128.150]) by c8a.amsl.com (Postfix) with ESMTPSA id 693D71D06DD; Tue, 2 Oct 2018 09:46:30 -0700 (PDT) To: Justin Uberti , Adam Roach Cc: Peter Thatcher , RTCWeb IETF , Cullen Jennings , Christer Holmberg , ice@ietf.org References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> From: Heather Flanagan Message-ID: <35975d78-76b7-b317-c43a-2a57e33198e7@rfc-editor.org> Date: Tue, 2 Oct 2018 09:47:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------682A0A1FF2E5BA1B6425480C" Content-Language: en-US Archived-At: Subject: Re: [Ice] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 16:46:56 -0000 This is a multi-part message in MIME format. --------------682A0A1FF2E5BA1B6425480C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks for copying me in, Adam. I definitely agree that this level of change is significant enough that it can't be handled in AUTH48. But, better it be right than fast! -Heather On 10/1/18 1:27 PM, Justin Uberti wrote: > [dropping some DLs] > > I think this is probably a day of work, but will probably take 2 weeks > to author and get approval for. > > If we go down this path, I would also suggest taking the two pending > PRs in JSEP, which will also impact the examples. > https://github.com/rtcweb-wg/jsep/pull/849 > https://github.com/rtcweb-wg/jsep/pull/850 > > > On Mon, Oct 1, 2018 at 1:23 PM Justin Uberti > wrote: > > I think this is probably a day of work, but will probably take 2 > weeks to author and get approval for. > > If we go down this path, I would also suggest taking the two > pending PRs in JSEP, which will also impact the examples. > https://github.com/rtcweb-wg/jsep/pull/849 > https://github.com/rtcweb-wg/jsep/pull/850 > > On Mon, Oct 1, 2018 at 12:17 PM Adam Roach > wrote: > > On 9/27/18 6:20 PM, Justin Uberti wrote: > > I agree with Peter. Chrome's implementation is already > closer to 8445 > > than 5245, so I don't see any issues associated with > snapping this > > cluster to 8445 (aside from the work involved). > > > > On that topic, note that JSEP will need a few more changes > than just > > the addition of the 8445 reference and note; the examples > will have to > > be updated, as will the logic regarding generation of offers > and > > answers and their parsing (to deal with the new ice-option). > These > > changes will be modest but probably will need to be done by > the authors. > > > If I read what you're saying correctly, it sounds like you're > talking > about changes that are significant enough that we'll have to > put JSEP > through IETF last call and through the IESG again. That being > the case, > and the rest of the cluster being so close to done, I'd really > prefer to > see this done very soon, if such changes are required. When do > you > believe such an update could be available? > > I've copied the RFC Series Editor on this note for her awareness. > > /a > --------------682A0A1FF2E5BA1B6425480C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Thanks for copying me in, Adam. I definitely agree that this level of change is significant enough that it can't be handled in AUTH48. But, better it be right than fast!


-Heather

On 10/1/18 1:27 PM, Justin Uberti wrote:
[dropping some DLs]

I think this is probably a day of work, but will probably take 2 weeks to author and get approval for.

If we go down this path, I would also suggest taking the two pending PRs in JSEP, which will also impact the examples.

On Mon, Oct 1, 2018 at 1:23 PM Justin Uberti <juberti@google.com> wrote:
I think this is probably a day of work, but will probably take 2 weeks to author and get approval for.

If we go down this path, I would also suggest taking the two pending PRs in JSEP, which will also impact the examples.

On Mon, Oct 1, 2018 at 12:17 PM Adam Roach <adam@nostrum.com> wrote:
On 9/27/18 6:20 PM, Justin Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8445
> than 5245, so I don't see any issues associated with snapping this
> cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just
> the addition of the 8445 reference and note; the examples will have to
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These
> changes will be modest but probably will need to be done by the authors.


If I read what you're saying correctly, it sounds like you're talking
about changes that are significant enough that we'll have to put JSEP
through IETF last call and through the IESG again. That being the case,
and the rest of the cluster being so close to done, I'd really prefer to
see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

--------------682A0A1FF2E5BA1B6425480C-- From nobody Tue Oct 2 12:58:50 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD99130E92; Mon, 1 Oct 2018 12:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSpEDjv9_5CL; Mon, 1 Oct 2018 12:17:41 -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 30841130DE8; Mon, 1 Oct 2018 12:17:41 -0700 (PDT) Received: from Svantevit.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 w91JHUjh039495 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 Oct 2018 14:17:34 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Justin Uberti , pthatcher=40google.com@dmarc.ietf.org Cc: mmusic@ietf.org, art@ietf.org, clue@ietf.org, ice@ietf.org, RTCWeb IETF , Cullen Jennings , Christer Holmberg , "Heather Flanagan (RFC Series Editor)" References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> From: Adam Roach Message-ID: <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> Date: Mon, 1 Oct 2018 14:17:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 02 Oct 2018 12:58:49 -0700 Subject: Re: [Ice] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 19:17:42 -0000 On 9/27/18 6:20 PM, Justin Uberti wrote: > I agree with Peter. Chrome's implementation is already closer to 8445 > than 5245, so I don't see any issues associated with snapping this > cluster to 8445 (aside from the work involved). > > On that topic, note that JSEP will need a few more changes than just > the addition of the 8445 reference and note; the examples will have to > be updated, as will the logic regarding generation of offers and > answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the authors. If I read what you're saying correctly, it sounds like you're talking about changes that are significant enough that we'll have to put JSEP through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer to see this done very soon, if such changes are required. When do you believe such an update could be available? I've copied the RFC Series Editor on this note for her awareness. /a From nobody Tue Oct 2 12:58:55 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BDB130EAF for ; Mon, 1 Oct 2018 13:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbrX-Va_htZY for ; Mon, 1 Oct 2018 13:23:56 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 6ECCC130EA8 for ; Mon, 1 Oct 2018 13:23:51 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id h6-v6so7175696ith.0 for ; Mon, 01 Oct 2018 13:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zvp0kTIHPh/XIYPP5qZyZT/abN+RvWchgBf/TDH9e1I=; b=SSCkQC8hFD8HM+JNRItHwTI/osDRh3eJenKTh2RwRVJjkn/kHkmhpW/W8gxGNPGgKJ REnw3ye0H1eP+Z71x/0tkzvPUiOB2vYFVLjpbz9miC+jQnHQhZ88ANyv+huUk0ZhDzOL 58QtOlsTGFgJ9yRlsH+tvE9UmYReRIR7sJdpuajNKacU5aAdQqrjnk7lKSvzuwaE3jHK XVrs1GIO3b8z1lhfo6i2SPo39M/XqSOVDJtqr3c8hC+AiWSfyLIPuFqipLDPwQGbXmV1 rF/ZG+EVtdSOQ5aAPuDdz1+AbmAps9FwxEV9Y388svaP5WUyajT6XHKcY7krrxTQ0V3U 7/rA== 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=zvp0kTIHPh/XIYPP5qZyZT/abN+RvWchgBf/TDH9e1I=; b=ZfYMMuV5FmEiuREp+vTv/4i3oG2sv0D/1yU4CrxcWTsAZLmx5cOJr/dSA+KSm402WQ 9oE0Pp/DR9jxCbSy5jE3s/CRi2d3NcBMPYI7/JCX/1mKIx4+wDVhbI0wAnYHMElzLEQp F+M42lxiISZ0b3LqeBmTzqP1KCqsNyRNDTytR1MVY0RB9i26Eg+3jYcZ1cmfPIQiba06 mAqxp3gl61OWAuzRl3zHL922/XA1G0l2+9ZtBDUSn5SY8uqKDLP4x9nGb4EU7Rqxlm9a C1xjHIwjFQDTejNyhj0RW8wDRM2yTcjHYUXgRUcuV8amg0qzuCTZWAEnak/ZJGkyeMoX h9eg== X-Gm-Message-State: ABuFfoih7Yv1Ytj1YMV0pY8rSK6OcOc8nepz/Az8VW2aDmaj6DGUN+SK MAILGVzIA2TldMm5PJfD6JZuEccKAnf977y8AkXR9w== X-Google-Smtp-Source: ACcGV60297gLXkGRFYopxbjnmtEp8h/+1ZvxWQf6qgvX1M29e6eSbtpj/ajXk71+LrpMckTDJIMrGKRo3+WfNCn4OTE= X-Received: by 2002:a24:6401:: with SMTP id t1-v6mr12375846itc.135.1538425430427; Mon, 01 Oct 2018 13:23:50 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> In-Reply-To: <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> From: Justin Uberti Date: Mon, 1 Oct 2018 13:23:36 -0700 Message-ID: To: Adam Roach Cc: Peter Thatcher , mmusic@ietf.org, art@ietf.org, clue@ietf.org, ice@ietf.org, RTCWeb IETF , Cullen Jennings , Christer Holmberg , "Heather Flanagan (RFC Series Editor)" Content-Type: multipart/alternative; boundary="0000000000004bcb1405773095fc" Archived-At: X-Mailman-Approved-At: Tue, 02 Oct 2018 12:58:49 -0700 Subject: Re: [Ice] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:24:05 -0000 --0000000000004bcb1405773095fc Content-Type: text/plain; charset="UTF-8" I think this is probably a day of work, but will probably take 2 weeks to author and get approval for. If we go down this path, I would also suggest taking the two pending PRs in JSEP, which will also impact the examples. https://github.com/rtcweb-wg/jsep/pull/849 https://github.com/rtcweb-wg/jsep/pull/850 On Mon, Oct 1, 2018 at 12:17 PM Adam Roach wrote: > On 9/27/18 6:20 PM, Justin Uberti wrote: > > I agree with Peter. Chrome's implementation is already closer to 8445 > > than 5245, so I don't see any issues associated with snapping this > > cluster to 8445 (aside from the work involved). > > > > On that topic, note that JSEP will need a few more changes than just > > the addition of the 8445 reference and note; the examples will have to > > be updated, as will the logic regarding generation of offers and > > answers and their parsing (to deal with the new ice-option). These > > changes will be modest but probably will need to be done by the authors. > > > If I read what you're saying correctly, it sounds like you're talking > about changes that are significant enough that we'll have to put JSEP > through IETF last call and through the IESG again. That being the case, > and the rest of the cluster being so close to done, I'd really prefer to > see this done very soon, if such changes are required. When do you > believe such an update could be available? > > I've copied the RFC Series Editor on this note for her awareness. > > /a > > --0000000000004bcb1405773095fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think= this is probably a day of work, but will probably take 2 weeks to author a= nd get approval for.

If we go down this path, I would al= so suggest taking the two pending PRs in JSEP, which will also impact the e= xamples.

On Mon, Oct 1, 2018 at 12:17 PM Adam Roach <adam@nostrum.com> wrote:
On 9/27/18 6:20 PM, Justin Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8= 445
> than 5245, so I don't see any issues associated with snapping this=
> cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just <= br> > the addition of the 8445 reference and note; the examples will have to=
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the author= s.


If I read what you're saying correctly, it sounds like you're talki= ng
about changes that are significant enough that we'll have to put JSEP <= br> through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer t= o
see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

--0000000000004bcb1405773095fc-- From nobody Tue Oct 9 06:31:06 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB10213131B; Tue, 9 Oct 2018 06:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChPp8oaLbKSl; Tue, 9 Oct 2018 06:31:02 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48646131312; Tue, 9 Oct 2018 06:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2228; q=dns/txt; s=iport; t=1539091862; x=1540301462; h=to:from:subject:message-id:date:mime-version; bh=1eQiAX8nr5VNersfkKVrhFmkl7aY/7c08L+7lEnUq1I=; b=dHtErh2n3WrVeTM0ZyDBhqzCSQPhKhjqLKU/Cf2wFkUqbwMCp2EQs4/2 Q5Npvc4blzm72WNa0w0FiFFOI7DE/1Q/srE7wnfHamjBzs9yix4eHCFpV 2HxMrAHV4h9roMmwft2WALxA9pxvJnXd1XG4FOgKz2FW330GOYDrFPmu0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAQAwrbxb/5RdJa0ZAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFlAgGBDHeBZYQdlEeBaIkeiDaFQYF5DYk3ITsHDAEDAQE?= =?us-ascii?q?CAQECbSiFY28GAT0CXwEMCAEBgx2BdQ2HSoElm02BLh+EWIUkizkXgUE/gTk?= =?us-ascii?q?MgjGBbwGGPYJXAp12CZBEBheBToRngmiGYpV3gVwNEYFVTSMVgyiCMY4/I40?= =?us-ascii?q?CAQE?= X-IronPort-AV: E=Sophos;i="5.54,360,1534809600"; d="scan'208,217";a="182831438" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 13:30:42 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTP id w99DUgXX012881; Tue, 9 Oct 2018 13:30:42 GMT To: mmusic , "ice@ietf.org" From: Flemming Andreasen Message-ID: Date: Tue, 9 Oct 2018 09:30:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1FD39C2E299169C2E66AD5EA" Content-Language: en-US X-Outbound-SMTP-Client: 10.118.10.21, rtp-fandreas-2-8814.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [Ice] Agenda Requests for ICE and MMUSIC in Bangkok (IETF 103) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 13:31:04 -0000 This is a multi-part message in MIME format. --------------1FD39C2E299169C2E66AD5EA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit ICE & MMUSIC WGs, At the Bangkok IETF meeting there will be no ICE WG session but we have a 2-hour MMUSIC session (currently scheduled for 13:50-15:50) which is also for any ICE related discussions, in particular related to the Cluster 238 documents. If you have any requests for agenda time, please contact the MMUSIC chairs no later than Monday, October 22. Regards,     ICE & MMUSIC chairs --------------1FD39C2E299169C2E66AD5EA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
ICE & MMUSIC WGs,

At the Bangkok IETF meeting there will be no ICE WG session but we have a 2-hour MMUSIC session (currently scheduled for 13:50-15:50) which is also for any ICE related discussions, in particular related to the Cluster 238 documents. If you have any requests for agenda time, please contact the MMUSIC chairs no later than Monday, October 22.

Regards,
   
    ICE & MMUSIC chairs

--------------1FD39C2E299169C2E66AD5EA-- From nobody Tue Oct 9 06:33:51 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923ED131322 for ; Tue, 9 Oct 2018 06:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.955 X-Spam-Level: X-Spam-Status: No, score=-14.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6-MpK7CSXba for ; Tue, 9 Oct 2018 06:33:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48676131333 for ; Tue, 9 Oct 2018 06:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4528; q=dns/txt; s=iport; t=1539092027; x=1540301627; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=XVNDUsQMORrW2p0pFCjRJfvKF9ZxkqynGBujOKF8YP8=; b=ZPLtOoEjpz75MRURe62aoxrpgovsoNewSd9FY70OpzPtQx7YkQ/c2lVx v7E2DH+3JSFhYNje3ayM55Uz1albaKLu5xquEscnQHO8qqhDVHx1VEu/S JJ9JPQJ0EgrQuryiaRW+Y8flyVJ1N0VDZKZccSOuhbBsICxdgxbmlWEVR 4=; X-Files: Attached Message Part : 121 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcBABarbxb/4kNJK0ZAUocAQIEAQg?= =?us-ascii?q?EAYFmAoENd2Z/KIN1lEeCDYh5iDaHOg0YAQqESQKESSE4FgEDAQECAQECbRw?= =?us-ascii?q?BC4U5AQIBAwEBIUsbCQYNAwECKwICAiUmAggGDQYCAQGDHQGBdA0Phz2BJZt?= =?us-ascii?q?NgS4fhFiFFQoFizkXgUE/gTmCPS6BQQGBWQEBgXgJgmGCVwKddgmEBYFpilY?= =?us-ascii?q?GF4FOhGeCaIZilXeBWSGBVU0jFTuCbIIyiGWFWiMwjFIBAQ?= X-IronPort-AV: E=Sophos;i="5.54,360,1534809600"; d="scan'208,217";a="183403630" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 13:33:46 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w99DXjgF023641 for ; Tue, 9 Oct 2018 13:33:45 GMT References: To: "ice@ietf.org" From: Flemming Andreasen X-Forwarded-Message-Id: Message-ID: <71326e13-549b-d610-bb60-acde2277148c@cisco.com> Date: Tue, 9 Oct 2018 09:33:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------10DFA8C2333BAFD7F3161682" Content-Language: en-US X-Outbound-SMTP-Client: 10.118.10.21, rtp-fandreas-2-8814.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: [Ice] Fwd: Agenda Requests for ICE and MMUSIC in Bangkok (IETF 103) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 13:33:50 -0000 This is a multi-part message in MIME format. --------------10DFA8C2333BAFD7F3161682 Content-Type: multipart/alternative; boundary="------------6C39EC0F326BB0EBFE3F27A0" --------------6C39EC0F326BB0EBFE3F27A0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit -------- Forwarded Message -------- Subject: [Ice] Agenda Requests for ICE and MMUSIC in Bangkok (IETF 103) Date: Tue, 9 Oct 2018 09:30:40 -0400 From: Flemming Andreasen To: mmusic , ice@ietf.org ICE & MMUSIC WGs, At the Bangkok IETF meeting there will be no ICE WG session but we have a 2-hour MMUSIC session (currently scheduled for 13:50-15:50) which is also for any ICE related discussions, in particular related to the Cluster 238 documents. If you have any requests for agenda time, please contact the MMUSIC chairs no later than Monday, October 22. Regards,     ICE & MMUSIC chairs --------------6C39EC0F326BB0EBFE3F27A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


-------- Forwarded Message --------
Subject: [Ice] Agenda Requests for ICE and MMUSIC in Bangkok (IETF 103)
Date: Tue, 9 Oct 2018 09:30:40 -0400
From: Flemming Andreasen <fandreas@cisco.com>
To: mmusic <mmusic@ietf.org>, ice@ietf.org <ice@ietf.org>


ICE & MMUSIC WGs,

At the Bangkok IETF meeting there will be no ICE WG session but we have a 2-hour MMUSIC session (currently scheduled for 13:50-15:50) which is also for any ICE related discussions, in particular related to the Cluster 238 documents. If you have any requests for agenda time, please contact the MMUSIC chairs no later than Monday, October 22.

Regards,
   
    ICE & MMUSIC chairs

--------------6C39EC0F326BB0EBFE3F27A0-- --------------10DFA8C2333BAFD7F3161682 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSWNlIG1h aWxpbmcgbGlzdApJY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pY2UKCg== --------------10DFA8C2333BAFD7F3161682-- From nobody Fri Oct 12 08:14:17 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99F8130E39 for ; Fri, 12 Oct 2018 08:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 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_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUAPsocZ5NZ6 for ; Fri, 12 Oct 2018 08:14:02 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 B1107130E2F for ; Fri, 12 Oct 2018 08:13:58 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id z25-v6so18253923wmf.1 for ; Fri, 12 Oct 2018 08:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=etlBKbGm6Rx8jUhwiuTFvHYu0MfcO87t/ldv6ckv7zE=; b=kbBh2vZCT06dAV3ddSrKPchglwtC8qRWjrgpG1GC3QjX9AXBxSApO3aKOtzujZ1GJH NuaKnRCqMOOIKiLpGPK0amWRJB6IHtvqv0lyw6V0VrOXiQFEOWW5z9ZfJNtom9rVUMth srAF3yf6cO4smgde0l/2PxMpQUxisblBkAKKgyCCmJD0MulxYe/FnS8SVUeAZK+mM6nd A02AV7eei3jIPsSy7umZW+OCNqoRBLDTnCKdcbOj4iiCZ/ezz/JDHJ3xqztfpYQtVnHA WV2BiJHi//Y+F18B0VtqjPKvciwJluxjT2iBwYlIagr2XtbQIQQ+QfI2r1qurIdAV6O6 dUlA== 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=etlBKbGm6Rx8jUhwiuTFvHYu0MfcO87t/ldv6ckv7zE=; b=e/O0woP4V0Bc0Z7rjO06PpMfkO6nLB7CTYn7w+JbKt7fmg/auFYdPDM8gPtqF0l8SI gpNk5ahV3H96xHMtj7SUKnow/DfmhasesaWRj6LVk/Kd4Ko6Ck/iavaLrc+4PQsJlnmi 6XcGDCSgZLAdwTdQMLvznOm5MnnBSBjhOf/CKfuGoE3xHKUtbypowcmueM6D5lVrvHDZ KaWO2ThbuIK9hpG9o2w176o26y/pe97jv+3SyCwoNeuU5CXWBkkcZtsqNo6jknCDG9eO 3nsXWpNjBj+6vqQfszrpDSeR49ocoiteTc8KQP3MyCoLJE66IPNLRft0AUtFZdg+aveX CAaQ== X-Gm-Message-State: ABuFfojD+J3wVXrESp3i3JH2e5gWF+WdZYaFIZMFpbisSqe2bbDumUWK DZ1aC3SN3gv6w6fmOcU99lVCT/5kgGjrRnjVMYCNRA== X-Google-Smtp-Source: ACcGV634Ej7c20K7On6ejzP2cAt8eLYIXpqP4/04vMUVSZ5LAKuB4CO37p/gwM5vXcwoWcgRzkxkf0aZRDqFdo1DeUI= X-Received: by 2002:a1c:838a:: with SMTP id f132-v6mr5822773wmd.51.1539357236687; Fri, 12 Oct 2018 08:13:56 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> In-Reply-To: From: Peter Thatcher Date: Fri, 12 Oct 2018 08:13:43 -0700 Message-ID: To: Justin Uberti Cc: pthatcher=40google.com@dmarc.ietf.org, mmusic@ietf.org, art@ietf.org, clue@ietf.org, ice@ietf.org, RTCWeb IETF , Cullen Jennings , Christer Holmberg Content-Type: multipart/alternative; boundary="00000000000047047205780989dd" Archived-At: Subject: Re: [Ice] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 15:14:05 -0000 --00000000000047047205780989dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 27, 2018 at 4:21 PM Justin Uberti wrote: > I agree with Peter. Chrome's implementation is already closer to 8445 tha= n > 5245, so I don't see any issues associated with snapping this cluster to > 8445 (aside from the work involved). > > On that topic, note that JSEP will need a few more changes than just the > addition of the 8445 reference and note; the examples will have to be > updated, as will the logic regarding generation of offers and answers and > their parsing (to deal with the new ice-option). These changes will be > modest but probably will need to be done by the authors. > > I've updated the references to 8445 (and to draft-ietf-mmusic-ice-sip-sdp) in this PR: https://github.com/rtcweb-wg/jsep/pull/851 I've also added the ice2 processing and added ice2 to the examples in the same PR. What did you mean by "and note"? Is there something more needed? > On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher 40google.com@dmarc.ietf.org> wrote: > >> I'm late to the discussion, and reading through it, it seems that we hav= e >> a lot of back and forth without addressing Cullen's root issue. Let me = see >> if I understand Cullen's root issue correctly. I think it's something l= ike: >> >> 1. Cisco has existing code that it wants to call "WebRTC 1.0 compliant" >> without changing to be compliant with 8445. >> >> 2. Cisco has existing code that it wants to continue to interoperate >> with endpoints, especially Chrome, even as they make changes to become 8= 445 >> compliant. And they don't want to have to test against old and new >> versions. >> >> Cullen, is that accurate? >> >> >> >> OK, so some of my thoughts: >> >> 1. I don't think there is any interop risk here at all related to >> timings. If you're worried about the drop in minimum check interval goi= ng >> from 20ms to 5ms, don't. Just because the spec allows for going that lo= w >> doesn't mean endpoints will. And if they do, they'll do it carefully. >> Endpoints can and should still choose a value that works best regardless= of >> the min in the spec. For example, Chrome is still using an interval of >> 48ms (we're not in a rush to lower it, but we have non-browser endpoints >> that do go lower). And if we roll out a lower value, it will be via >> experiments or opt-ins and carefully tracked to make sure connectivity >> rates don't drop. If any problem were found in practice, it would be >> quickly reverted. >> >> 2. I don't think there is any interop risk here related to nomination >> either. >> Chrome's default behavior has never been compliant to any spec anyway, >> and it's never been an issue. And like with ping intervals, any changes= to >> implementations will be done slowly and carefully. >> >> 3. I don't think it really matters to major implementations what the >> dependency graph looks like. Whether some point to 5245 and others to 8= 445 >> or if all of them point to 8445, it doesn't matter, implementations will >> behave the same either way. Chrome, for example will adjust timings as >> works well in practice (perhaps someday to below 20ms interval) regardle= ss >> of which RFCs point to 8445 and which point to 5245. If interop issues >> ever do come up, then they can be fixed. And that has nothing to do wit= h >> which RFCs point to 5245 and which point to 8445. >> >> 5. You're going to need to test against different versions of different >> browser no matter what the RFC references are. ICE timings and nominati= ons >> seem like the least of your testing problems. But on the flip side, Chr= ome >> (and I assume other browsers) have been very slow and careful when makin= g >> changes to the ICE code. >> >> 6. FlexICE should go a long way to putting the web app in control of th= e >> ICE behavior. So if you are worried about what browsers will do with IC= E, >> I suggest supporting the FlexICE effort. In fact, it's the result of yo= ur >> proposal at TPAC in 2017 for wanting to have lower-level of control of >> ICE... If we get that into all the browsers, you won't have to worry an= y >> more about any of this because you'll be in control (assuming you contro= l >> the web app). >> > >> Altogether, I don't see any reason to not reference 8445 everywhere, at >> least not any related to interop risk and web browsers. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings wrote: >> >>> >>> On Sep 7, 2018, at 1:25 AM, Christer Holmberg < >>> christer.holmberg@ericsson..com > wrote= : >>> >>> > Cisco has implemented stuff that is WebRTC 1.0 compliant without this >>> change. These gratuitous changes, years after the implementation were >>> coded, with no real benefit will ensure that we are not >>> > and will not become compliant with the RFC. It's unlikely we will >>> upgrade to the new ICE until it has real befits. >>> >>> The main reason we did 8445 was because people had identified issues >>> with 5245. The work was driven mostly by the WebRTC community, includin= g >>> yourself and the Chrome people (or, at least the Google people), and on= e of >>> the reason it took time to finalize 8445 was because you (among others) >>> wanted to make sure we get things right (by making network measurements >>> etc). Are you now saying all those changes bring no benefit? Did we all >>> waste our time? >>> >>> >>> Our testing, which we do not share, dig not indicate an improvement of >>> connectivity rates. I did not see results from others that did. Some of= the >>> early test results from others that drove this work were not reproducib= le >>> in our testing. The one thing I think most people did find is that the = more >>> out of sync the pacing of the two agents was, the worse the connectivit= y >>> was. But all of this is water under the bridge, we have old and new ice= , >>> people can use either. What we are talking about here is what is the >>> minimum bar for WebRTC 1.0 >>> >>> >>> > It is doubtful Justin will want to implement the 8445 mechanisms of >>> supporting both new and old ICE. Instead, we will move to say "works >>> with Browser X version Y or later." We have watched at W3C as it moved = to >>> be that unless chrome does it, it rare that it becomes a standard. >>> > Right here I am watching how the stuff IETF defines will be less >>> relevant than the issue of what chrome implements. >>> >>> What exactly would Justin have to change? >>> >>> >>> >>> For us, the largest part is having to test for both old and new - it=E2= =80=99s >>> not easy to do good automated testing for ICE. >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> _______________________________________________ > > >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --00000000000047047205780989dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Sep 27, 2018 at 4:21 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
I agree with Peter. Chro= me's implementation is already closer to 8445 than 5245, so I don't= see any issues associated with snapping this cluster to 8445 (aside from t= he work involved).

On that topic, note that JSEP will ne= ed a few more changes than just the addition of the 8445 reference and note= ; the examples will have to be updated, as will the logic regarding generat= ion of offers and answers and their parsing (to deal with the new ice-optio= n). These changes will be modest but probably will need to be done by the a= uthors.


I've updated th= e references to 8445 (and to=C2=A0draft-ietf-mmusic-ice-sip-sdp) in this PR= :=C2=A0https://githu= b.com/rtcweb-wg/jsep/pull/851

I've also ad= ded the ice2 processing and added ice2 to the examples in the same PR.=C2= =A0

What did you mean by "and note"?=C2= =A0 Is there something more needed?
=C2=A0
<= div dir=3D"ltr">On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher <pthatche= r=3D40goog= le.com@dmarc.ietf.org> wrote:
I'm late to th= e discussion, and reading through it, it seems that we have a lot of back a= nd forth without addressing Cullen's root issue.=C2=A0 Let me see if I = understand Cullen's root issue correctly.=C2=A0 I think it's someth= ing like:

1.=C2=A0 Cisco has existing code that it= wants to call "WebRTC 1.0 compliant" without changing to be comp= liant with 8445.

2.=C2=A0 Cisco has existing code = that it wants to continue to interoperate with endpoints, especially Chrome= , even as they make changes to become 8445 compliant.=C2=A0 And they don= 9;t want to have to test against old and new versions.=C2=A0=C2=A0

Cullen, is that accurate?



OK, so some of my thoughts:

1.=C2=A0 I don't think there is any interop risk here at all related t= o timings.=C2=A0 If you're worried about the drop in minimum check inte= rval going from 20ms to 5ms, don't.=C2=A0 Just because the spec allows = for going that low doesn't mean endpoints will.=C2=A0 And if they do, t= hey'll do it carefully.=C2=A0 Endpoints can and should still choose a v= alue that works best regardless of the min in the spec.=C2=A0 For example, = Chrome is still using an interval of 48ms (we're not in a rush to lower= it, but we have non-browser endpoints that do go lower).=C2=A0 And if we r= oll out a lower value, it will be via experiments or opt-ins and carefully = tracked to make sure connectivity rates don't drop.=C2=A0 If any proble= m were found in practice, it would be quickly reverted.=C2=A0=C2=A0

2.=C2=A0 I don't think there is any interop risk here= related to nomination either.=C2=A0=C2=A0
Chrome's default b= ehavior has never been compliant to any spec anyway, and it's never bee= n an issue.=C2=A0 And like with ping intervals, any changes to implementati= ons will be done slowly and carefully.=C2=A0=C2=A0

3.=C2=A0 I don't think it really matters to major implementations what= the dependency graph looks like.=C2=A0 Whether some point to 5245 and othe= rs to 8445 or if all of them point to 8445, it doesn't matter, implemen= tations will behave the same either way.=C2=A0 Chrome, for example will adj= ust timings as works well in practice (perhaps someday to below 20ms interv= al) regardless of which RFCs point to 8445 and which point to 5245.=C2=A0 I= f interop issues ever do come up, then they can be fixed.=C2=A0 And that ha= s nothing to do with which RFCs point to 5245 and which point to 8445.

5.=C2=A0 You're going to need to test against diff= erent versions of different browser no matter what the RFC references are.= =C2=A0 ICE timings and nominations seem like the least of your testing prob= lems.=C2=A0 But on the flip side, Chrome (and I assume other browsers) have= been very slow and careful when making changes to the ICE code.
=
6.=C2=A0 FlexICE should go a long w= ay to putting the web app in control of the ICE behavior.=C2=A0 So if you a= re worried about what browsers will do with ICE, I suggest supporting the F= lexICE effort.=C2=A0 In fact, it's the result of your proposal at TPAC = in 2017 for wanting to have lower-level of control of ICE...=C2=A0 If we ge= t that into all the browsers, you won't have to worry any more about an= y of this because you'll be in control (assuming you control the web ap= p).=C2=A0

Altogether, I d= on't see any reason to not reference 8445 everywhere, at least not any = related to interop risk and web browsers.







=C2=A0









<= /blockquote>
On Fri, Sep 7= , 2018 at 9:37 AM Cullen Jennings <fluffy@iii.ca> wrote:

On Sep 7, 2018, at 1:25 AM, Christer = Holmberg <christer.holmberg@ericsson..com> wrote:

> C= isco has implemented stuff that is WebRTC 1.0 compliant without this change= .=C2=A0These gratuitous changes, y= ears after the implementation were coded, with no real benefit will ensure = that we are not
>=C2=A0and will not= become compliant with the RFC.=C2=A0It's unlikely we will upgrade to the new ICE until it has real befit= s.=C2=A0
= =C2=A0
The main reason we di= d 8445 was because people had identified issues with 5245. The work was dri= ven mostly by the WebRTC community, including yourself and the Chrome peopl= e (or, at least the Google people), and one of the reason it took time to f= inalize 8445 was because you (among others) wanted to make sure we get thin= gs right (by making network measurements etc). Are you now saying all those= changes bring no benefit? Did we all waste our time?

Our testing, which we do not share, d= ig not indicate an improvement of connectivity rates. I did not see results= from others that did. Some of the early test results from others that drov= e this work were not reproducible in our testing. The one thing I think mos= t people did find is that the more out of sync the pacing of the two agents= was, the worse the connectivity was. But all of this is water under the br= idge, we have old and new ice, people can use either. What we are talking a= bout here is what is the minimum bar for WebRTC 1.0=C2=A0

=C2=A0=
> It is doubtful Justin = will want to implement the 8445 mechanisms of supporting both new and old I= CE.=C2=A0Instead, we will move to = say "works with Browser X version Y or later." We have watched at= W3C as it moved to be that unless chrome does it, it rare that it becomes = a standard. =C2=A0
>=C2=A0Right her= e I am watching how the stuff IETF defines will be less relevant than the i= ssue of what chrome implements.=C2=A0=
= =C2=A0
What exactl= y would Justin have to change?
=C2=A0

For us, the largest part is having to test for both old and new - it= =E2=80=99s not easy to do good automated testing for ICE.=C2=A0
= _______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--00000000000047047205780989dd-- From nobody Fri Oct 12 18:09:02 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13003130E96 for ; Fri, 12 Oct 2018 18:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXxSPkZSLkvH for ; Fri, 12 Oct 2018 18:08:47 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 C3C8A130E92 for ; Fri, 12 Oct 2018 18:08:44 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id e74-v6so20621760ita.2 for ; Fri, 12 Oct 2018 18:08:44 -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=ZvnkrFDKS2tvIfI4jJqEb63gbq43fw9zgj6Fo/uFPGQ=; b=HY9k6sPH8AwHFqiTqDrKoZrt2+oiGv4wnkLgO2EJ2X+Xwe/NuVMJLDF+BXs+8UVrqv OwU35yytFJ8BahZEQqzcm9ClCZEbzJeGmaZChOncxBqwIx+W6ML5SIIwgeIKjOZ2wMZ0 VC9z0R0oRWHcN3al4nNBQbf0xNBFhQqlb6LfxhauoHaic/0AlPJWfFjDtaa2k8Kgl0Mi C/8RLksxpqFvp6+qA6WsMwF4mMihJoByhUVTrWDJ8UGq9his1q39j7Udy4uXTj/l0UcY C3Gt0B9GxReliBZP1hCPfYgk2GLqzC5c6TRc7qfCdWyaqMEzFr1iRjOjV/A+8fkG1FwR JiaQ== 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=ZvnkrFDKS2tvIfI4jJqEb63gbq43fw9zgj6Fo/uFPGQ=; b=igsTqBjG6eY25apiHWGai5+t5ImnNAW3ecsWYI4Hf1y54q4XbfrPPCWkN+T4IZnrh1 MVgDdxeu2ml7m3tq/3i3/Q1iMQDHGHi7Psv9mRYGAt8uwvy6v7tWARr78il/jQ6RRPPc UaqazF97Xsw/4ecBq820c8wFDRr44tLhWRH250ZhL+dFOQ7BwPVwRfY7AaGQs9MIbGL/ gn8JvpZmatPYVmm2UW8OZU97YgwT1tlg46UvVxMJwuRcD+KNQ8wNLONMvFMTwwDK8ncA G0z1L3BsuPbLLanZhWOjbgSSAqVZcjgze6kZxuqw+u7K9KTW3DKJe/EYnZ+vYAXmuFIs cTOA== X-Gm-Message-State: ABuFfohyItYKrXGwGNl0Ze/JSXhm5E79nhd1QU4p1jPMnIjQlrJ/UId8 XQhSHLP9U2mmkUT5nebtMM5lKIcqyPwDh8if3U9c4Q== X-Google-Smtp-Source: ACcGV63ndaLILfkWGr55imIClvCOJ3JtTzCJeZ4VsYmNIX8q2gBRPm1dEyM+CcrCiwJIiVQ5Ia89iSVo6PHpklJ2piM= X-Received: by 2002:a24:fc02:: with SMTP id b2-v6mr6257023ith.45.1539392923522; Fri, 12 Oct 2018 18:08:43 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> In-Reply-To: From: Justin Uberti Date: Fri, 12 Oct 2018 18:08:29 -0700 Message-ID: To: pthatcher=40google.com@dmarc.ietf.org Cc: Peter Thatcher , mmusic@ietf.org, art@ietf.org, clue@ietf.org, ice@ietf.org, RTCWeb IETF , Cullen Jennings , Christer Holmberg Content-Type: multipart/alternative; boundary="00000000000060d8e5057811d87f" Archived-At: Subject: Re: [Ice] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 01:08:49 -0000 --00000000000060d8e5057811d87f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 12, 2018 at 8:14 AM Peter Thatcher wrote: > > > On Thu, Sep 27, 2018 at 4:21 PM Justin Uberti 40google.com@dmarc.ietf.org> wrote: > >> I agree with Peter. Chrome's implementation is already closer to 8445 >> than 5245, so I don't see any issues associated with snapping this clust= er >> to 8445 (aside from the work involved). >> >> On that topic, note that JSEP will need a few more changes than just the >> addition of the 8445 reference and note; the examples will have to be >> updated, as will the logic regarding generation of offers and answers an= d >> their parsing (to deal with the new ice-option). These changes will be >> modest but probably will need to be done by the authors. >> >> > I've updated the references to 8445 (and to draft-ietf-mmusic-ice-sip-sdp= ) > in this PR: https://github.com/rtcweb-wg/jsep/pull/851 > > I've also added the ice2 processing and added ice2 to the examples in the > same PR. > Thanks for doing this, Peter. > > What did you mean by "and note"? Is there something more needed? > The note in question is the text that Adam mentioned in the original email: *While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245], and use a pre-standard version of the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one. * I do think we need text similar to this to be added to S 5.11 (processing an answer) in JSEP. > > >> On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher > 40google.com@dmarc.ietf.org> wrote: >> >>> I'm late to the discussion, and reading through it, it seems that we >>> have a lot of back and forth without addressing Cullen's root issue. L= et >>> me see if I understand Cullen's root issue correctly. I think it's >>> something like: >>> >>> 1. Cisco has existing code that it wants to call "WebRTC 1.0 compliant= " >>> without changing to be compliant with 8445. >>> >>> 2. Cisco has existing code that it wants to continue to interoperate >>> with endpoints, especially Chrome, even as they make changes to become = 8445 >>> compliant. And they don't want to have to test against old and new >>> versions. >>> >>> Cullen, is that accurate? >>> >>> >>> >>> OK, so some of my thoughts: >>> >>> 1. I don't think there is any interop risk here at all related to >>> timings. If you're worried about the drop in minimum check interval go= ing >>> from 20ms to 5ms, don't. Just because the spec allows for going that l= ow >>> doesn't mean endpoints will. And if they do, they'll do it carefully. >>> Endpoints can and should still choose a value that works best regardles= s of >>> the min in the spec. For example, Chrome is still using an interval of >>> 48ms (we're not in a rush to lower it, but we have non-browser endpoint= s >>> that do go lower). And if we roll out a lower value, it will be via >>> experiments or opt-ins and carefully tracked to make sure connectivity >>> rates don't drop. If any problem were found in practice, it would be >>> quickly reverted. >>> >>> 2. I don't think there is any interop risk here related to nomination >>> either. >>> Chrome's default behavior has never been compliant to any spec anyway, >>> and it's never been an issue. And like with ping intervals, any change= s to >>> implementations will be done slowly and carefully. >>> >>> 3. I don't think it really matters to major implementations what the >>> dependency graph looks like. Whether some point to 5245 and others to = 8445 >>> or if all of them point to 8445, it doesn't matter, implementations wil= l >>> behave the same either way. Chrome, for example will adjust timings as >>> works well in practice (perhaps someday to below 20ms interval) regardl= ess >>> of which RFCs point to 8445 and which point to 5245. If interop issues >>> ever do come up, then they can be fixed. And that has nothing to do wi= th >>> which RFCs point to 5245 and which point to 8445. >>> >>> 5. You're going to need to test against different versions of differen= t >>> browser no matter what the RFC references are. ICE timings and nominat= ions >>> seem like the least of your testing problems. But on the flip side, Ch= rome >>> (and I assume other browsers) have been very slow and careful when maki= ng >>> changes to the ICE code. >>> >>> 6. FlexICE should go a long way to putting the web app in control of >>> the ICE behavior. So if you are worried about what browsers will do wi= th >>> ICE, I suggest supporting the FlexICE effort. In fact, it's the result= of >>> your proposal at TPAC in 2017 for wanting to have lower-level of contro= l of >>> ICE... If we get that into all the browsers, you won't have to worry a= ny >>> more about any of this because you'll be in control (assuming you contr= ol >>> the web app). >>> >> >>> Altogether, I don't see any reason to not reference 8445 everywhere, at >>> least not any related to interop risk and web browsers. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings wrote: >>> >>>> >>>> On Sep 7, 2018, at 1:25 AM, Christer Holmberg < >>>> christer.holmberg@ericsson..com > >>>> wrote: >>>> >>>> > Cisco has implemented stuff that is WebRTC 1.0 compliant without thi= s >>>> change.. These gratuitous changes, years after the implementation were >>>> coded, with no real benefit will ensure that we are not >>>> > and will not become compliant with the RFC. It's unlikely we will >>>> upgrade to the new ICE until it has real befits. >>>> >>>> The main reason we did 8445 was because people had identified issues >>>> with 5245. The work was driven mostly by the WebRTC community, includi= ng >>>> yourself and the Chrome people (or, at least the Google people), and o= ne of >>>> the reason it took time to finalize 8445 was because you (among others= ) >>>> wanted to make sure we get things right (by making network measurement= s >>>> etc). Are you now saying all those changes bring no benefit? Did we al= l >>>> waste our time? >>>> >>>> >>>> Our testing, which we do not share, dig not indicate an improvement of >>>> connectivity rates. I did not see results from others that did. Some o= f the >>>> early test results from others that drove this work were not reproduci= ble >>>> in our testing. The one thing I think most people did find is that the= more >>>> out of sync the pacing of the two agents was, the worse the connectivi= ty >>>> was. But all of this is water under the bridge, we have old and new ic= e, >>>> people can use either. What we are talking about here is what is the >>>> minimum bar for WebRTC 1.0 >>>> >>>> >>>> > It is doubtful Justin will want to implement the 8445 mechanisms of >>>> supporting both new and old ICE. Instead, we will move to say "works >>>> with Browser X version Y or later." We have watched at W3C as it moved= to >>>> be that unless chrome does it, it rare that it becomes a standard. >>>> > Right here I am watching how the stuff IETF defines will be less >>>> relevant than the issue of what chrome implements. >>>> >>>> What exactly would Justin have to change? >>>> >>>> >>>> >>>> For us, the largest part is having to test for both old and new - it= =E2=80=99s >>>> not easy to do good automated testing for ICE. >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> _______________________________________________ >> >> >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > --00000000000060d8e5057811d87f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Fri, Oct 12, 2018 at 8:14 AM Peter Thatcher <pthatcher= =3D40googl= e.com@dmarc.ietf.org> wrote:


On Thu, Sep 27, 2018 at 4:21 PM Justin Uberti <juberti=3D<= a href=3D"mailto:40google.com@dmarc.ietf.org" target=3D"_blank">40google.co= m@dmarc.ietf.org> wrote:
I agree with Peter. Chrome's implement= ation is already closer to 8445 than 5245, so I don't see any issues as= sociated with snapping this cluster to 8445 (aside from the work involved).=

On that topic, note that JSEP will need a few more chan= ges than just the addition of the 8445 reference and note; the examples wil= l have to be updated, as will the logic regarding generation of offers and = answers and their parsing (to deal with the new ice-option). These changes = will be modest but probably will need to be done by the authors.


I've updated the references to 84= 45 (and to=C2=A0draft-ietf-mmusic-ice-sip-sdp) in this PR:=C2=A0https://githu= b.com/rtcweb-wg/jsep/pull/851

I've also ad= ded the ice2 processing and added ice2 to the examples in the same PR.=C2= =A0

Thanks for doing this= , Peter.=C2=A0=C2=A0

What did y= ou mean by "and note"?=C2=A0 Is there something more needed?

The note in question is the t= ext that Adam mentioned in the original email:

= While this specification formally relies on [RFC8445], at the time of its p= ublication, the majority of WebRTC implementations support the version of I= CE described in [RFC5245], and use a pre-standard version of the trickle ic= e mechanism described in [RFCXXXX]. The use of the "ice2" attribu= te defined in [RFC8445] can be used to detect the version in use by a remot= e endpoint and to provide a smooth transition from the older specification = to the newer one.=C2=A0

I do think we n= eed text similar to this to be added to S 5.11 (processing an answer) in JS= EP.
=C2=A0
On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher <pt= hatcher=3D= 40google.com@dmarc.ietf.org> wrote:
I'm late to the discussion, and reading through it, it seems tha= t we have a lot of back and forth without addressing Cullen's root issu= e.=C2=A0 Let me see if I understand Cullen's root issue correctly.=C2= =A0 I think it's something like:

1.=C2=A0 Cisc= o has existing code that it wants to call "WebRTC 1.0 compliant" = without changing to be compliant with 8445.

2.=C2= =A0 Cisco has existing code that it wants to continue to interoperate with = endpoints, especially Chrome, even as they make changes to become 8445 comp= liant.=C2=A0 And they don't want to have to test against old and new ve= rsions.=C2=A0=C2=A0

Cullen, is that accurate?



OK, so some of my though= ts:

1.=C2=A0 I don't think there is any intero= p risk here at all related to timings.=C2=A0 If you're worried about th= e drop in minimum check interval going from 20ms to 5ms, don't.=C2=A0 J= ust because the spec allows for going that low doesn't mean endpoints w= ill.=C2=A0 And if they do, they'll do it carefully.=C2=A0 Endpoints can= and should still choose a value that works best regardless of the min in t= he spec.=C2=A0 For example, Chrome is still using an interval of 48ms (we&#= 39;re not in a rush to lower it, but we have non-browser endpoints that do = go lower).=C2=A0 And if we roll out a lower value, it will be via experimen= ts or opt-ins and carefully tracked to make sure connectivity rates don'= ;t drop.=C2=A0 If any problem were found in practice, it would be quickly r= everted.=C2=A0=C2=A0

2.=C2=A0 I don't think th= ere is any interop risk here related to nomination either.=C2=A0=C2=A0
Chrome's default behavior has never been compliant to any spec an= yway, and it's never been an issue.=C2=A0 And like with ping intervals,= any changes to implementations will be done slowly and carefully.=C2=A0=C2= =A0

3.=C2=A0 I don't think it really matters t= o major implementations what the dependency graph looks like.=C2=A0 Whether= some point to 5245 and others to 8445 or if all of them point to 8445, it = doesn't matter, implementations will behave the same either way.=C2=A0 = Chrome, for example will adjust timings as works well in practice (perhaps = someday to below 20ms interval) regardless of which RFCs point to 8445 and = which point to 5245.=C2=A0 If interop issues ever do come up, then they can= be fixed.=C2=A0 And that has nothing to do with which RFCs point to 5245 a= nd which point to 8445.

5.=C2=A0 You're going = to need to test against different versions of different browser no matter w= hat the RFC references are.=C2=A0 ICE timings and nominations seem like the= least of your testing problems.=C2=A0 But on the flip side, Chrome (and I = assume other browsers) have been very slow and careful when making changes = to the ICE code.

6.=C2=A0 FlexICE should go a long way to putting the web app in = control of the ICE behavior.=C2=A0 So if you are worried about what browser= s will do with ICE, I suggest supporting the FlexICE effort.=C2=A0 In fact,= it's the result of your proposal at TPAC in 2017 for wanting to have l= ower-level of control of ICE...=C2=A0 If we get that into all the browsers,= you won't have to worry any more about any of this because you'll = be in control (assuming you control the web app).=C2=A0

Altogether, I don't s= ee any reason to not reference 8445 everywhere, at least not any related to= interop risk and web browsers.






=C2= =A0




<= br>




On = Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings <fluffy@iii.ca> wrote:

On Sep 7, 2018, at 1:25 AM, Chr= ister Holmberg <christer.holmberg@ericsson..com> wrote:

> Cisco has implemented stu= ff that is WebRTC 1.0 compliant without this change..=C2=A0These g= ratuitous changes, years after the implementation were coded, with no real = benefit will ensure that we are not
>=C2=A0and will not become comp= liant with the RFC.=C2=A0It's unlikely we will upgrade to the = new ICE until it has real befits.=C2=A0
<= /u>=C2=A0
The main reason we did= 8445 was because people had identified issues with 5245. The work was driv= en mostly by the WebRTC community, including yourself and the Chrome people= (or, at least the Google people), and one of the reason it took time to fi= nalize 8445 was because you (among others) wanted to make sure we get thing= s right (by making network measurements etc). Are you now saying all those = changes bring no benefit? Did we all waste our time?

Our testing, which we do not share, dig not indicate an impro= vement of connectivity rates. I did not see results from others that did. S= ome of the early test results from others that drove this work were not rep= roducible in our testing. The one thing I think most people did find is tha= t the more out of sync the pacing of the two agents was, the worse the conn= ectivity was. But all of this is water under the bridge, we have old and ne= w ice, people can use either. What we are talking about here is what is the= minimum bar for WebRTC 1.0=C2=A0

=C2=A0
>= It is doubtful Justin will want to implement the 8445 mechanisms of suppor= ting both new and old ICE.=C2=A0Instead, we will move to say "= ;works with Browser X version Y or later." We have watched at W3C as i= t moved to be that unless chrome does it, it rare that it becomes a standar= d. =C2=A0
>=C2=A0Right here I am watching how the stuff IETF define= s will be less relevant than the issue of what chrome implements.=C2=A0
=C2=A0
What exactly would Justin have to change?<= /u>
=C2=A0<= /div>

For us, the largest part is having to test for both old a= nd new - it=E2=80=99s not easy to do good automated testing for ICE.=C2=A0<= /div>
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--00000000000060d8e5057811d87f-- From nobody Sat Oct 13 02:23:37 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBA4130ED3; Sat, 13 Oct 2018 02:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOFA15A1GPTX; Sat, 13 Oct 2018 02:23:11 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 778F5130DFB; Sat, 13 Oct 2018 02:23:11 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id e4-v6so15854539wrs.0; Sat, 13 Oct 2018 02:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sp9Nt9uE+JXulHdZQVT+BwLv9NztoQ+Rd9dmHrMralQ=; b=BT7QJGNmalxTS/AWqWfTAmxpgd+VQtm7Ucl0+OnfQZ3L4915LIEe3BK4nCwtHaGzLE Zw8mKNoWpWuhUwYE39uziadui6MpaqwGuB+wYknJfiPLsE76s1j+qaNEeLUwCSCP/bb/ cmEGIN7LeqX2306QVgo/hwP2dfbLn4pj/B6rXSbtUUd/N2BrVlvUwpHp/poEzNHEYf7a ISiJgT0JcYALp6uY1/lLY7L/9tat8EsgUWoDr8/lElNOxPl4Z+QMfR8NdsPIhiThoEoM fETCnE7yK34tcu77aidgmcKyBFUxZkqdHfda8jsZqpTG5pTfvWFxv9+AvTQGLM7/Vvje wPLg== 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=Sp9Nt9uE+JXulHdZQVT+BwLv9NztoQ+Rd9dmHrMralQ=; b=SStcxfpebV7wg/GrIcyl5eLL/kTxjHB3YBZJ69o+QTIkUpKXXyl6Pw9v1d44b0YIj4 B3PeVPMJWIALzskmct4mh6jE7oftAms+W16QZ7lLOKN5xoF6bJkgIizJefh7mlYvX7vh QR3vsPhlFfRHSNXaz0YHt0BPu/yijhDq2GQ0j+WTINhbnAMypRZjdzm7i0FTAqJ1lmVG 8+kRLhfye+fIqQf+1/cm8AN6wweneotMc4imjdDFGPL8dgw2Bh/19gG9PuxRFH+Na1g2 gdXvSiRqHnhvuNFHCXjj8EM5hOHJ8MI21D1OAbJKELbTQqN/6OGYB+BWaSmcVVYvFPj6 oKqw== X-Gm-Message-State: ABuFfojBlIYT7b5ZVpSkig0hKI+1pb7SwaKnUCDfu2iHm3w0Ll6VZpmI cpS8dUOHhPY9IDGONj/u3+h7FyVNRHvWDL4zBAdomw== X-Google-Smtp-Source: ACcGV60WWQuevL5fbD3oz4Gs8DzWxJeznaO8eAY/OgVF7CNyE1S+aMdU+7QwPHRRsrhRK2IcaVCgP1tz9/wrtcUzjcg= X-Received: by 2002:a5d:6648:: with SMTP id f8-v6mr8226804wrw.218.1539422589907; Sat, 13 Oct 2018 02:23:09 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> In-Reply-To: <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> From: Sergio Garcia Murillo Date: Sat, 13 Oct 2018 11:22:58 +0200 Message-ID: To: Adam Roach Cc: Justin Uberti , pthatcher=40google.com@dmarc.ietf.org, mmusic@ietf.org, art@ietf.org, "Heather Flanagan (RFC Series Editor)" , clue@ietf.org, ice@ietf.org, RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000a1789e057818c0bb" Archived-At: Subject: Re: [Ice] [rtcweb] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 09:23:14 -0000 --000000000000a1789e057818c0bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable p0090 El lun., 1 oct. 2018 23:11, Adam Roach escribi=C3=B3: > On 9/27/18 6:20 PM, Justin Uberti wrote: > > I agree with Peter. Chrome's implementation is already closer to 8445 > > than 5245, so I don't see any issues associated with snapping this > > cluster to 8445 (aside from the work involved). > > > > On that topic, note that JSEP will need a few more changes than just > > the addition of the 8445 reference and note; the examples will have to > > be updated, as will the logic regarding generation of offers and > > answers and their parsing (to deal with the new ice-option). These > > changes will be modest but probably will need to be done by the authors= . > > > If I read what you're saying correctly, it sounds like you're talking > about changes that are significant enough that we'll have to put JSEP > through IETF last call and through the IESG again. That being the case, > and the rest of the cluster being so close to done, I'd really prefer to > see this done very soon, if such changes are required. When do you > believe such an update could be available? > > I've copied the RFC Series Editor on this note for her awareness. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000a1789e057818c0bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
p0090

El lun., 1 oct. 2018 23:11, Adam Roach <adam@nostrum.com> escribi=C3=B3:
On 9/27/18 6:20 PM, Justin Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8= 445
> than 5245, so I don't see any issues associated with snapping this=
> cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just <= br> > the addition of the 8445 reference and note; the examples will have to=
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the author= s.


If I read what you're saying correctly, it sounds like you're talki= ng
about changes that are significant enough that we'll have to put JSEP <= br> through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer t= o
see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

_______________________________________________
rtcweb mailing list
rtc= web@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb<= /a>
--000000000000a1789e057818c0bb-- From nobody Sat Oct 13 16:45:28 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB911130E7C for ; Sat, 13 Oct 2018 16:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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_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 js9d5p-MFiTA for ; Sat, 13 Oct 2018 16:45:23 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 243201277D2 for ; Sat, 13 Oct 2018 16:45:23 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id q4-v6so11772965iob.8 for ; Sat, 13 Oct 2018 16:45:23 -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=jcav3Zv9jT+jSncH5KgVBc4qYS1iX5y9XRNbI59zj6Q=; b=PnD5g2AXuKDVRdgCN1Z/lxQ2fhi8CoPWBDsNyncVVQSV5s6aHq1kVipYCqz4h+PcLU 60JSLnM2rwAcCPqK6y1KxMfIlzBBB+lpc8+/qT1Z9PNnF8hCIOU4dZx0N+EzT1XNdJmc br1LLoffoVdGuELccdKSAPr7z6sKeG5pfNE8iHJV970iBLSNiRMAUFOHJTohhoCvxpQ6 x2Lts75hXUzahRly/XXota5w6uL+A97csW5DLEj+ojnhN7kEUvwSWFmBHXryyNbP55O8 ns2fMnVC6ZKMxmBMgCP0E+tQnpz9d7hxnAbzf8BkHOOiDoZDD2ggl2KQatjU7xhf8yV6 4fSg== 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=jcav3Zv9jT+jSncH5KgVBc4qYS1iX5y9XRNbI59zj6Q=; b=ezlsWebsACeM8tx7eO0KKrWUojrmUQbjVoctLChFRfpmFV8p7PeriAWJvQzkLShH5L cme956TSy22k+ZCsYhZPKXi8mPAY6SwmitPRKTE0eKHqocuhsQHk8bPUr5QGjmwi8Yba foWlbZ1CK/2irDOGtHUQHMxE1jYHZRpoxB5Nf0WVwP8U+FR4wHv0p/92C/exuN2kwHNo +dAzVWVvPWP1l/ht8eP4bpB/vGyq4Qabb4scL0Z+xrMxIyTIrDHymllJ9nrs7EmZOJoD uVN7zzinwAGFXwDGfrezBrz1/Wjerp7VQE93cFF0w8CiBkix/UovYlTjDwGuY2m+0Tpu SyIQ== X-Gm-Message-State: ABuFfohsh80RIsYDVRCpCkTjiFXC2pbddLx/sIzbqNY2LxHdSxblMyYu NJH0VWzRCHBhInwscpxNe1WegGxzI1uEKlp26SsY1Q== X-Google-Smtp-Source: ACcGV614kY2yqpiKv5B3ESSAUHSb6aC1AZpKmDb3VB4qR+zCURaHSkF5zdOcJHsvMIU3NdFavEplpylfIGn44EALVq8= X-Received: by 2002:a6b:39c3:: with SMTP id g186-v6mr8512807ioa.32.1539474322029; Sat, 13 Oct 2018 16:45:22 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> In-Reply-To: From: Justin Uberti Date: Sat, 13 Oct 2018 16:45:09 -0700 Message-ID: To: Christer Holmberg Cc: Sergio Garcia Murillo , Adam Roach , "Heather Flanagan (RFC Series Editor)" , pthatcher=40google.com@dmarc.ietf.org, ice@ietf.org, RTCWeb IETF , juberti=40google.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="0000000000001b9730057824cc19" Archived-At: Subject: Re: [Ice] [MMUSIC] [clue] [rtcweb] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 23:45:26 -0000 --0000000000001b9730057824cc19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [removing DLs again] We are taking a few other outstanding issues as part of this rev (potentially including https://github.com/rtcweb-wg/jsep/issues/843 which you noted), so I think a new LC is warranted. Aiming for a new doc version on Monday. On Sat, Oct 13, 2018 at 1:50 PM Justin Uberti wrote: > We are taking a few other outstanding issues as part of this rev > (potentially including https://github.com/rtcweb-wg/jsep/issues/843 which > you noted), so I think a new LC is warranted. > > Aiming for a new doc version on Monday. > > On Sat, Oct 13, 2018 at 2:52 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> Personally I don't think updating of references and examples require a >> new IETF last call. >> >> >> Do people foresee any changes to the technical JSEP procedures due to th= e >> reference update? >> >> >> Regards, >> >> >> Christer >> >> >> ------------------------------ >> *From:* clue on behalf of Sergio Garcia Murillo = < >> sergio.garcia.murillo@gmail.com> >> *Sent:* Saturday, October 13, 2018 12:22 PM >> *To:* Adam Roach >> *Cc:* mmusic@ietf.org; art@ietf.org; Heather Flanagan (RFC Series >> Editor); clue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; >> ice@ietf.org; RTCWeb IETF; Justin Uberti >> *Subject:* Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and >> Cluster 238 >> >> p0090 >> >> El lun., 1 oct. 2018 23:11, Adam Roach > > escribi=C3=B3: >> >> On 9/27/18 6:20 PM, Justin Uberti wrote: >> > I agree with Peter. Chrome's implementation is already closer to 8445 >> > than 5245, so I don't see any issues associated with snapping this >> > cluster to 8445 (aside from the work involved). >> > >> > On that topic, note that JSEP will need a few more changes than just >> > the addition of the 8445 reference and note; the examples will have to >> > be updated, as will the logic regarding generation of offers and >> > answers and their parsing (to deal with the new ice-option). These >> > changes will be modest but probably will need to be done by the author= s. >> >> >> If I read what you're saying correctly, it sounds like you're talking >> about changes that are significant enough that we'll have to put JSEP >> through IETF last call and through the IESG again. That being the case, >> and the rest of the cluster being so close to done, I'd really prefer to >> see this done very soon, if such changes are required. When do you >> believe such an update could be available? >> >> I've copied the RFC Series Editor on this note for her awareness. >> >> /a >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > --0000000000001b9730057824cc19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 13, 2018 at 1:50 PM Justin Uberti <juberti@google.com> wrote:
We are taking a = few other outstanding issues as part of this rev (potentially including htt= ps://github.com/rtcweb-wg/jsep/issues/843 which you noted), so I think = a new LC is warranted.

Aiming for= a new doc version on Monday.

On Sat, Oct 13, 2018 at 2:52 AM Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer= .holmberg@ericsson.com> wrote:

Hi,


Personally I don't think upda= ting of references and examples require a new IETF last call.


Do people foresee any changes to = the technical JSEP procedures due to the reference update?=C2=A0


Regards,


Christer



From: clue <clue-bounces@ietf.org> on behalf of Sergio Garcia = Murillo <sergio.garcia.murillo@gmail.com>
Sent: Saturday, October 13, 2018 12:22 PM
To: Adam Roach
Cc: mmusic@ietf= .org; art@ietf.org; Heather Flanagan (RFC Series Editor); clue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; ice@ietf.org; RTCWeb IETF= ; Justin Uberti
Subject: Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and = Cluster 238
=C2=A0
p0090

El lun., 1 oct. 2018 23:11, Adam Roach <adam@nostrum.com> escribi=C3=B3:
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--0000000000001b9730057824cc19-- From nobody Sat Oct 13 22:10:37 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3391130ED8 for ; Sat, 13 Oct 2018 02:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.755 X-Spam-Level: X-Spam-Status: No, score=-4.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=IgY+nIJH; dkim=pass (1024-bit key) header.d=ericsson.com header.b=YOy4l/Xp 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 szfHBvFdAhLK for ; Sat, 13 Oct 2018 02:51:53 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC4D130EBC for ; Sat, 13 Oct 2018 02:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539424310; x=1542016310; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lKlxjdC35O2VYGx9uMNra32Rtcl6p6vmUAkJcSzGSmI=; b=IgY+nIJHoDlVKZM0A0hke62pGc9/+3LosEex2xP4XXPQoOgtNxGZoRDI2vRoYSx6 9EcslwrYNkmmNMuJY39YsMsqDpPn1JIsXNDX2rAOik0Q5SDn8+v5W/3um8x+IUTb +DDzzW11t2oFmP5pgCcUMC4hZzP6oyprlaLcnNQGsoI=; X-AuditID: c1b4fb2d-b37ff70000003a27-86-5bc1c036d5d5 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.03.14887.630C1CB5; Sat, 13 Oct 2018 11:51:50 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 13 Oct 2018 11:51:50 +0200 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 13 Oct 2018 11:51:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lKlxjdC35O2VYGx9uMNra32Rtcl6p6vmUAkJcSzGSmI=; b=YOy4l/XpUDtRfjPZBzbLrHOdhscyra0SVIlMsPCjIjIU596bm+hPSQQZ2Vv3AZJDoCHXsMI9ycsV13bYiWK83UXIb3DcsE6Q68KUUA1Q45bwifgb6kdtbboQF7ygHYGmubBNR6BQSFZStq/G78tx5w+jk7nHriANORv6QxMKsec= Received: from VI1PR07MB4782.eurprd07.prod.outlook.com (20.177.57.157) by VI1PR07MB1248.eurprd07.prod.outlook.com (10.164.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.16; Sat, 13 Oct 2018 09:51:48 +0000 Received: from VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221]) by VI1PR07MB4782.eurprd07.prod.outlook.com ([fe80::39f7:7dd7:dc40:4221%6]) with mapi id 15.20.1228.020; Sat, 13 Oct 2018 09:51:48 +0000 From: Christer Holmberg To: Sergio Garcia Murillo , Adam Roach CC: "mmusic@ietf.org" , "art@ietf.org" , "Heather Flanagan (RFC Series Editor)" , "clue@ietf.org" , "pthatcher=40google.com@dmarc.ietf.org" , "ice@ietf.org" , RTCWeb IETF , Justin Uberti Thread-Topic: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHUYtZlrUrVsNmXpkqzWCK6GAjkWKUc7mmn Date: Sat, 13 Oct 2018 09:51:48 +0000 Message-ID: References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [91.150.32.117] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1248; 6:vq39JdaAxL+EJVzhq0/hmOtkTHCGspJPWBDJCB/KAHmlCjBGPPbC0aOrerGth3x4zi5d7bPQjrSJImp8vrgrh0/EMGbeZ9AK6kQGX2tnNgEQhdhQB0E3gYM4/EGACe65fmK9RFPePX8xSYbZrhdIT33BAlOky8FDFuU7IZAXlh49tZwjD+dZSY5EmXHPqnuHY5OB93igCaPDXHnw/13Cswi1KPqkOMCFxDLaVdJKzyKrhVFJowI9iYJObL+/6Z7V7CyLIa7Uzf43Muptf8y3QYzG0ljBDiaKYY1Ae/Uyo/BEqH4a5t70ZVZ0vVT9V76JuotQ3q7Vf+2dUcfkSzP3Zdd51xtgIEozFucvwzPTy8yAZE+hyBuwoC101X82EFqHEFq+KNAbt01MJqcHxKxnbf6KoHG7y0gW/TOHEjbGPydQH/+ios64fE+PGoD2ge+LwR3Pww0wsgYmTUYgbyIbSA==; 5:PjIa4vstPU2SliO66TXvzLwaG7Ceh3oNSCgTJ/mOXd1Je//9q4gyuUuXPkW9jj/iiXssEVijUdXpQSto9EXFswpzMi2YDLKufxFkKDJ3+q4H4QSmsZpNmJElVYxHTrLhpn2yZ6uXO74hZZ5dMiIfgZiARxkAyiGTP/bsCJ4gOR4=; 7:PUOs0Kv0iC3HkBDCo6f9uUS2UNq2TR4qOPdzyqMXYz/h6gQR/EWcEEH/O9gKs/m0HtbOKZ4ieVsz8l9czYZJIPZFjmVcOzOpSCVXhovQcIabSph0FsoXBE/iBVGsX7DZG0/gN9jRDrXJbSUzt6z8lRGqdSg+pAYrITsVOk5jkhRTY2IBLWarWgHhcq9CbOcfD8V/jz5X5I2d4TWTL8vHKLeOpCazV7mOTCGzNYnT3zZ726H82GEdao2sEJj8LveS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: dbceb871-a67b-430d-e774-08d630f17e46 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB1248; x-ms-traffictypediagnostic: VI1PR07MB1248: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201708071742011)(7699051); SRVR:VI1PR07MB1248; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1248; x-forefront-prvs: 082465FB26 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(346002)(396003)(366004)(189003)(199004)(7736002)(186003)(74316002)(53936002)(106356001)(476003)(33656002)(11346002)(26005)(19627405001)(446003)(606006)(54906003)(66066001)(25786009)(102836004)(2900100001)(44832011)(97736004)(4326008)(105586002)(110136005)(6606003)(486006)(256004)(71190400001)(1015004)(53546011)(7696005)(3846002)(6506007)(71200400001)(6246003)(76176011)(8936002)(229853002)(966005)(99286004)(6116002)(8676002)(81156014)(5250100002)(14444005)(14454004)(7416002)(6436002)(6306002)(39060400002)(2906002)(9686003)(93886005)(54896002)(5660300001)(86362001)(55016002)(236005)(68736007)(478600001)(316002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1248; H:VI1PR07MB4782.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: MrObq/Xnnrl/us2RhpOftIv2Xke/YyzS62IhrmCFQgo8TdiPEz/LooFmJkVU67P2YmW1GjZpht+fzhqoYFK+OH3qlNirnKlwX4GUIuVO85XztiHI5ezkPgAXuF2yfpQo+d9flyFRqtkT0I2u+xZPKZDO9aILXkdapkwNTEq7TMCVP0yfj3j+LKqwdje+LWY5JfQmloPhja5aU438Sbb75ZcNnsAdg9CcOfeUriZGKXsCfvYDg/DRtRkNY2XJEcgmriw5+J/h5yK7YKElphDOFS/nSI4hEEDwvJKk1qJLmV+F7B3Y/t+/+gooLn6N164+/4XQGBK4PLEBV/NZtDuI16+rLDC5rzpW7Px756xv084= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB47827124FFC94FD04A2C231693E30VI1PR07MB4782eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dbceb871-a67b-430d-e774-08d630f17e46 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2018 09:51:48.2390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1248 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+3bOtuNq8Lm8vFiWLSNRtkxFDiJqUbSCMrMg1C4jType2THR wFDxkq6LlZMc1bSGhiVe8YK3XJnmH2lqkbfhZWpihARqIq6cZ4H//d7neb73+T74KEIyznei YhKSGVWCMk4qEJEll5tSZb7vusI9cxb30m0bL4X06wkF3dk3RNArA+l0trqbT2sqZkh6OPMm PTbnR1eZ84T0rLmJCBIpesuH+YoW7YRQodev8RTaFhOpyMj9yD/PDxP5RzJxMSmM6kjAdVF0 lnoQJbV6pZYsjRAZqMijANlQgH2gSveTKEAiSoK7EdRWzAm4YQVBZu4TwpKSYD0P1v+4WAwS FxKQn/WQ5FKPeaCdbeFxwzSCvLpnmw5FCTANavNWhx2OgL9D7VsZAv/mwfDI7Nba3fgCbEze E3KhUBipaCQ59gLjyvQWk/gQNE81EJad4s1F6tVQrmucAL2mWGDJ2OAQMI5/41sYYQdY7XvL szCBHWHUpONxD8Wgb+snOLaHhRmzNa+EzspJq34A+j4bSI6dYVCnRpYywB1CGPsxwOcMGSxp NNYDZ6G2Y81a0INgfimEY3foz6y36rEwWtVnXeoH+vfrQo73QeX9KbIQeWq33ZXjRHiQ2Yss LMa28KnERHK6HL5rigQce0B52SLBsQyemg3kdr0UCSuRPcuwbHyUl7ecUcXcYNnEBHkCk1yH Nv9cV8O6rBm9WTxmQJhC0l3inuqucAlfmcKmxRsQUITUTsx4bkriSGXabUaVeE11K45hDWgP RUodxfLKtjAJjlImM7EMk8So/rs8ysYpA3l/OXlw2dhkV9Mewcw7z9SURgXtXHafo9uzKeFS bM5dv3OGV6c7aqvXzMETA/E6Y8CJ1i7/K53zrm7dO359la0v+Oiumj64kD6u3U8b/fLLRs8U 6HxbesLu0LLi/fXB6PmAXemLS82TZvFF74ZHgYdPOdQEHU8P7DDaBqs73bJ9pCQbrTzqTqhY 5T/nrQlkbwMAAA== Archived-At: X-Mailman-Approved-At: Sat, 13 Oct 2018 22:10:36 -0700 Subject: Re: [Ice] [clue] [rtcweb] [MMUSIC] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 09:51:56 -0000 --_000_VI1PR07MB47827124FFC94FD04A2C231693E30VI1PR07MB4782eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Personally I don't think updating of references and examples require a new = IETF last call. Do people foresee any changes to the technical JSEP procedures due to the r= eference update? Regards, Christer ________________________________ From: clue on behalf of Sergio Garcia Murillo Sent: Saturday, October 13, 2018 12:22 PM To: Adam Roach Cc: mmusic@ietf.org; art@ietf.org; Heather Flanagan (RFC Series Editor); cl= ue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; ice@ietf.org; RTCWeb = IETF; Justin Uberti Subject: Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster= 238 p0090 El lun., 1 oct. 2018 23:11, Adam Roach > escribi=F3: On 9/27/18 6:20 PM, Justin Uberti wrote: > I agree with Peter. Chrome's implementation is already closer to 8445 > than 5245, so I don't see any issues associated with snapping this > cluster to 8445 (aside from the work involved). > > On that topic, note that JSEP will need a few more changes than just > the addition of the 8445 reference and note; the examples will have to > be updated, as will the logic regarding generation of offers and > answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the authors. If I read what you're saying correctly, it sounds like you're talking about changes that are significant enough that we'll have to put JSEP through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer to see this done very soon, if such changes are required. When do you believe such an update could be available? I've copied the RFC Series Editor on this note for her awareness. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_VI1PR07MB47827124FFC94FD04A2C231693E30VI1PR07MB4782eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


Personally I don't think updating= of references and examples require a new IETF last call.


Do people foresee any changes to = the technical JSEP procedures due to the reference update? 


Regards,


Christer



From: clue <clue-bounces= @ietf.org> on behalf of Sergio Garcia Murillo <sergio.garcia.murillo@= gmail.com>
Sent: Saturday, October 13, 2018 12:22 PM
To: Adam Roach
Cc: mmusic@ietf.org; art@ietf.org; Heather Flanagan (RFC Series Edit= or); clue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; ice@ietf.org; = RTCWeb IETF; Justin Uberti
Subject: Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and = Cluster 238
 
p0090

El lun., 1 oct. 2018 23:11, Adam Roach <adam@nostrum.com> escribi=F3:
On 9/27/18 6:20 PM, Justin Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8445 =
> than 5245, so I don't see any issues associated with snapping this > cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just <= br> > the addition of the 8445 reference and note; the examples will have to=
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the author= s.


If I read what you're saying correctly, it sounds like you're talking
about changes that are significant enough that we'll have to put JSEP
through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer to see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.o= rg
https://www.ietf.org/mailman/listinfo/rtcweb
--_000_VI1PR07MB47827124FFC94FD04A2C231693E30VI1PR07MB4782eurp_-- From nobody Sat Oct 13 22:10:45 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E565130E91 for ; Sat, 13 Oct 2018 13:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqhCbJRQD-TK for ; Sat, 13 Oct 2018 13:50:23 -0700 (PDT) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 13487130E84 for ; Sat, 13 Oct 2018 13:50:21 -0700 (PDT) Received: by mail-it1-x136.google.com with SMTP id c23-v6so23589672itd.5 for ; Sat, 13 Oct 2018 13:50:21 -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=t4xcdnlSlQbK/yJ1P0DWsAnP+vIIIPEBDd8r4drN+ks=; b=M0aQZULkcpisDp2UKcrK1KvizKK4OxqGht4TmFL63y4k99P4qjd42IAh1CI+8X6s43 PRTvZDRKp+UeBaNyfROGxAy8KxH8nJqLGCQYmH70UKoh2Yop8+EpsjfkudgMh/cZa/TX dxqg1sOzYXF5+dqLJVWDZP5CuVNYbf7LoW+wk/9SLTtll1Rs+Q2mq3jrDkN1ucVftS/s Ha5N9s2CvHekMl3JJki9aNN9U7ZsbV8YBw7K92pv+SHrY5w5Eq/dwtO/gxLAMdAHWIgZ gwbIPmcr4sx5Gpb4+MeC1+j9JIAQHNfNPv7wsr8jmjVSm5naQzajdAXUJDEQTdokVL4u fs1A== 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=t4xcdnlSlQbK/yJ1P0DWsAnP+vIIIPEBDd8r4drN+ks=; b=IIONz+HOtvO7KFs2kWpvJgKV3ozF9fRfNjD25oUe/DiTSwywWUIH/l50kxVUgN+DZc Q4/zLZeKS8l1cTZdgqZrB7LBeZAVQiwCl3OmuPCMI08PLpWMnAJ37WHLvM+STnn75tSD VlklZJSjrPfCq8dqR1RCGapsKSX57o75GMkIo4d++v4+lAzsfruTjJfLn/ePO+bcSuiO FQ8XK5HIisQlZ/ibqokaKxgEE6QBnG9yTz4TDXhfhnzxrz+Y34ZGUiuDcuw0ieSP6uEd AY5D2vOrG1AYu0RZl67d+06Cd3UJrjNqAO1stYW6m3mCQn3EWM/fT0whtu9CYLQMMGZi /R4g== X-Gm-Message-State: ABuFfog3GEn47fr2RXhYbK65fwc7WvfRWUR3GYMprDSb7BaKXIebV4oC iGzMoDbhBNhCO0nmpUm/Tdm2oc7SkamULuNmZVawuA== X-Google-Smtp-Source: ACcGV609Ki7nnv6F2Ftbhr3/DWpyOrZTQrvlaEN98TSPC1hQgegEBOn+9DdD0wkqafZsxybqpjriP2UdBNXrofvxt1c= X-Received: by 2002:a24:9005:: with SMTP id x5-v6mr6718492itd.76.1539463819957; Sat, 13 Oct 2018 13:50:19 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <2f5dfed4-1f77-51cf-aec8-0d3e8e8edb14@nostrum.com> In-Reply-To: From: Justin Uberti Date: Sat, 13 Oct 2018 13:50:07 -0700 Message-ID: To: Christer Holmberg Cc: Sergio Garcia Murillo , Adam Roach , mmusic@ietf.org, art@ietf.org, "Heather Flanagan (RFC Series Editor)" , clue@ietf.org, pthatcher=40google.com@dmarc.ietf.org, ice@ietf.org, RTCWeb IETF , juberti=40google.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="00000000000022a5450578225a00" Archived-At: X-Mailman-Approved-At: Sat, 13 Oct 2018 22:10:36 -0700 Subject: Re: [Ice] [MMUSIC] [clue] [rtcweb] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 20:50:27 -0000 --00000000000022a5450578225a00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We are taking a few other outstanding issues as part of this rev (potentially including https://github.com/rtcweb-wg/jsep/issues/843 which you noted), so I think a new LC is warranted. Aiming for a new doc version on Monday. On Sat, Oct 13, 2018 at 2:52 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > Personally I don't think updating of references and examples require a ne= w > IETF last call. > > > Do people foresee any changes to the technical JSEP procedures due to the > reference update? > > > Regards, > > > Christer > > > ------------------------------ > *From:* clue on behalf of Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> > *Sent:* Saturday, October 13, 2018 12:22 PM > *To:* Adam Roach > *Cc:* mmusic@ietf.org; art@ietf.org; Heather Flanagan (RFC Series > Editor); clue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; > ice@ietf.org; RTCWeb IETF; Justin Uberti > *Subject:* Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and > Cluster 238 > > p0090 > > El lun., 1 oct. 2018 23:11, Adam Roach > escribi=C3=B3: > > On 9/27/18 6:20 PM, Justin Uberti wrote: > > I agree with Peter. Chrome's implementation is already closer to 8445 > > than 5245, so I don't see any issues associated with snapping this > > cluster to 8445 (aside from the work involved). > > > > On that topic, note that JSEP will need a few more changes than just > > the addition of the 8445 reference and note; the examples will have to > > be updated, as will the logic regarding generation of offers and > > answers and their parsing (to deal with the new ice-option). These > > changes will be modest but probably will need to be done by the authors= . > > > If I read what you're saying correctly, it sounds like you're talking > about changes that are significant enough that we'll have to put JSEP > through IETF last call and through the IESG again. That being the case, > and the rest of the cluster being so close to done, I'd really prefer to > see this done very soon, if such changes are required. When do you > believe such an update could be available? > > I've copied the RFC Series Editor on this note for her awareness. > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --00000000000022a5450578225a00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We are taking a few other outstanding iss= ues as part of this rev (potentially including https://github.com/rtcweb-wg/jsep/issues/843 which you noted), so I think a new LC is warranted.

Hi,


Personally I don't think upda= ting of references and examples require a new IETF last call.


Do people foresee any changes to = the technical JSEP procedures due to the reference update?=C2=A0


Regards,


Christer



From:= clue <clue-b= ounces@ietf.org> on behalf of Sergio Garcia Murillo <sergio.garcia.muri= llo@gmail.com>
Sent: Saturday, October 13, 2018 12:22 PM
To: Adam Roach
Cc: mmusic@ietf= .org; art@ietf.org; Heather Flanagan (RFC Series Editor); clue@ietf.org; pthatcher=3D40google.com@dmarc.ietf.org; ice@ietf.org; RTCWeb IETF= ; Justin Uberti
Subject: Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and = Cluster 238
=C2=A0
p0090

El lun., 1 oct. 2018 23:11, Adam Roach <adam@nostrum.com> = escribi=C3=B3:
On 9/27/18 6:20 PM, Justin Uberti wrote:
> I agree with Peter. Chrome's implementation is already closer to 8= 445
> than 5245, so I don't see any issues associated with snapping this=
> cluster to 8445 (aside from the work involved).
>
> On that topic, note that JSEP will need a few more changes than just <= br> > the addition of the 8445 reference and note; the examples will have to=
> be updated, as will the logic regarding generation of offers and
> answers and their parsing (to deal with the new ice-option). These > changes will be modest but probably will need to be done by the author= s.


If I read what you're saying correctly, it sounds like you're talki= ng
about changes that are significant enough that we'll have to put JSEP <= br> through IETF last call and through the IESG again. That being the case, and the rest of the cluster being so close to done, I'd really prefer t= o
see this done very soon, if such changes are required. When do you
believe such an update could be available?

I've copied the RFC Series Editor on this note for her awareness.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listin= fo/rtcweb
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--00000000000022a5450578225a00--