From nobody Mon Oct 1 14:56:25 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@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: Mon, 01 Oct 2018 14:56:23 -0700 Subject: Re: [clue] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence 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 Wed Oct 3 14:41:54 2018 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AA6130DC4; Wed, 3 Oct 2018 14:41:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk CC: adam@nostrum.com, "Daniel C. Burnett" , clue@ietf.org, roni.even@mail01.huawei.com, Roni Even , clue-chairs@ietf.org, draft-ietf-clue-signaling@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153860290360.8959.5364563864223377090.idtracker@ietfa.amsl.com> Date: Wed, 03 Oct 2018 14:41:43 -0700 Archived-At: Subject: [clue] Last Call: (Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 21:41:46 -0000 The IESG has received a request from the ControLling mUltiple streams for tElepresence WG (clue) to consider the following document: - 'Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-10-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2960/ https://datatracker.ietf.org/ipr/2272/ https://datatracker.ietf.org/ipr/2271/ https://datatracker.ietf.org/ipr/2959/ The document contains these normative downward references. See RFC 3967 for additional information: rfc7322: RFC Style Guide (Informational - IAB stream) rfc7202: Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution (Informational - IETF stream) draft-presta-clue-protocol: CLUE protocol (None - ) From nobody Wed Oct 3 14:44:21 2018 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED10130DD2; Wed, 3 Oct 2018 14:43:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk CC: adam@nostrum.com, "Daniel C. Burnett" , clue@ietf.org, pkyzivat@alum.mit.edu, clue-chairs@ietf.org, Paul Kyzivat , draft-ietf-clue-protocol@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153860303911.9136.1319798377563451676.idtracker@ietfa.amsl.com> Date: Wed, 03 Oct 2018 14:43:59 -0700 Archived-At: Subject: [clue] Last Call: (Protocol for Controlling Multiple Streams for Telepresence (CLUE)) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 21:44:13 -0000 The IESG has received a request from the ControLling mUltiple streams for tElepresence WG (clue) to consider the following document: - 'Protocol for Controlling Multiple Streams for Telepresence (CLUE)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-10-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2273/ https://datatracker.ietf.org/ipr/2274/ From nobody Sun Oct 7 00:12:19 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63254130D7A for ; Sun, 7 Oct 2018 00:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im2upCxYAvjH for ; Sun, 7 Oct 2018 00:12:17 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 ED356128D0C for ; Sun, 7 Oct 2018 00:12:16 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6CF6537FD56EE for ; Sun, 7 Oct 2018 08:12:12 +0100 (IST) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Sun, 7 Oct 2018 08:12:14 +0100 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.153]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0399.000; Sun, 7 Oct 2018 15:12:04 +0800 From: "Roni Even (A)" To: Adam Roach CC: Paul Kyzivat , "clue@ietf.org" Thread-Topic: CLUE almost done Thread-Index: AdReDOARyLLKoRf8QPKpsI0kor5XSQ== Date: Sun, 7 Oct 2018 07:12:03 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8E3BBA@dggemm526-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.172.208] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8E3BBAdggemm526mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [clue] CLUE almost done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 07:12:18 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8E3BBAdggemm526mbxchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, Thanks , looks like we are getting at last to the conclusion of CLUE Thanks Roni --_000_6E58094ECC8D8344914996DAD28F1CCD8E3BBAdggemm526mbxchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adam,

Thanks , looks like we are getting at last to the co= nclusion of CLUE

Thanks

Roni

--_000_6E58094ECC8D8344914996DAD28F1CCD8E3BBAdggemm526mbxchina_-- From nobody Wed Oct 10 11:10:27 2018 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AC7124D68; Wed, 10 Oct 2018 11:10:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke?= To: Cc: clue@ietf.org, ietf@ietf.org, draft-ietf-clue-signaling.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153919501667.5824.11176366846856816586@ietfa.amsl.com> Date: Wed, 10 Oct 2018 11:10:16 -0700 Archived-At: Subject: [clue] Opsdir last call review of draft-ietf-clue-signaling-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:10:17 -0000 Reviewer: Éric Vyncke Review result: Has Nits Reviewer: Eric Vyncke Review result: has minor nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. >From a deployment point of view, I liked this introduction statement "Backwards-compatibility is an important consideration of the protocol: it is vital that a CLUE-capable device contacting a device that does not support CLUE is able to fall back to a fully functional non-CLUE call." And special care of co-existence during deployement appear in the document. But, I wonder how *middle boxes* would react if they are not aware of this protocol extension. Please bear with my very light understanding of CLUE in general. As a side note, it would have been nice to expand the CLUE acronym when used the first time. In general, the document is not easy to read: too many details given immediately without a first high-level description. So, the sections 8 and 9 (examples) are really useful even if more details could have been given: for example, while the initial SDP is shown, the response SDP is not. Nits: section 6 has a reference which does not have a URI. Else, this document is ready to go. -éric From nobody Wed Oct 10 11:39:15 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865F9126CC7 for ; Wed, 10 Oct 2018 11:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 WBj2qbTAfyvq for ; Wed, 10 Oct 2018 11:39:10 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079BD127B92 for ; Wed, 10 Oct 2018 11:39:06 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id AJ41g8AJqBDnOAJNygLInl; Wed, 10 Oct 2018 18:39:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1539196746; bh=hbyWB395oHemAMFWItQtSbcuXbt2GU5sOmvE1HGUAwg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=bnl1WfE5Uj0dVejchKIsld6M39KyxzCKLtMXMMV1kCG6oTbw3OsG6d/84wlw50ktS umNeB12Zp+EtEY6RHQzwelAtJ3DOjPuaouWTa1KGGTpG3c4ty8wgvGseNl5KK9JRbH W6N15zJ2hOE8zXgZnCBCLn+DdwB2eXivqadWOngNSz0bGKCwVLKfsAIjBNj4nhQmv3 ntn9jHYugNiiOydbT1k7OtQodJGQ9RX9SRECMUOkrTXGnuEnGlFr4yrwe5D5B8V3Ef 2IC9Bh4kzjj3kMGB9990Ekg65VCsRi/P7L+xspDjcwJBxGz+dZ4JwlEIP4zSItVMQr ogmpV575fyT+g== Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-10v.sys.comcast.net with ESMTPA id AJNwgXbrvB5tvAJNxgodwp; Wed, 10 Oct 2018 18:39:05 +0000 To: =?UTF-8?Q?=c3=89ric_Vyncke?= Cc: clue@ietf.org, ietf@ietf.org, draft-ietf-clue-signaling.all@ietf.org References: <153919501667.5824.11176366846856816586@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <7f79eefb-0868-5fbd-8052-13e3d41ee98e@comcast.net> Date: Wed, 10 Oct 2018 14:39:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153919501667.5824.11176366846856816586@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfDq+QaNTHcgVzVLaheJ6tSWkgI+3YAo6nXQc7fuLdtQtJtbz4cPr4NMi48K5Eu53kCVD1+S60VxQecp2beDEcB3msFJuLK0fzjow4hn+nDnZTsrf8JQH w1She2S6Z1fNbxh3ds62hwQMPNh8ON0KkDKjCpRtMI0gKafYl0T8HeGR87bu5jNPFGz/BWNGbF0aUblA8K+h62moZLfPU5OtjcqW0UDiVcH0szTQB+uVEGdw Ozbo3/K2MNDvTb71Fg8Xfton30XBKqePCJGMSHQF5hkwDVfuBcpHtI/J4OkbkU1o Archived-At: Subject: Re: [clue] Opsdir last call review of draft-ietf-clue-signaling-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:39:14 -0000 Éric, On 10/10/18 2:10 PM, Éric Vyncke wrote: > Reviewer: Éric Vyncke > Review result: Has Nits > > Reviewer: Eric Vyncke > Review result: has minor nits > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. Comments that are not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs should > treat these comments just like any other last call comments. > >>From a deployment point of view, I liked this introduction statement > "Backwards-compatibility is an important consideration of the protocol: it is > vital that a CLUE-capable device contacting a device that does not support CLUE > is able to fall back to a fully functional non-CLUE call." And special care of > co-existence during deployement appear in the document. Thanks. It was a critical point for us! > But, I wonder how > *middle boxes* would react if they are not aware of this protocol extension. In general there is no need for existing middle boxes to understand it. From their perspective clue negotiations are just negotiations of sip sessions with multiple media streams. The use of bundle may have more impact on them, but those issues are dealt with as part of the bundle spec. Middle boxes that are restrictive, such as forbidding multiple audio or video streams, might cause trouble. But we can't do anything about that. Of course it may be possible to imagine a middle box that wants to do something special with clue, but it would need to understand clue to do that. Thanks, Paul [Note: I omitted opsdir from the mailing list in my reply in anticipation that it would be rejected because I don't subscribe to it.] > Please bear with my very light understanding of CLUE in general. As a side > note, it would have been nice to expand the CLUE acronym when used the first > time. In general, the document is not easy to read: too many details given > immediately without a first high-level description. So, the sections 8 and 9 > (examples) are really useful even if more details could have been given: for > example, while the initial SDP is shown, the response SDP is not. > > Nits: section 6 has a reference which does not have a URI. > > Else, this document is ready to go. > > -éric > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Oct 10 11:57:13 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EA1124BE5; Wed, 10 Oct 2018 11:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 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, 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 zF0qFxdHAnqM; Wed, 10 Oct 2018 11:57:09 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C5A126F72; Wed, 10 Oct 2018 11:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4278; q=dns/txt; s=iport; t=1539197827; x=1540407427; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Yjw6IhtNMrOSKgZ3b3bqYuDpHXMm3izN+iEtgB26NVU=; b=QjjE0NRtAYqc92mrCPPMvdTtipKhxMcCyKpr+nu/kxuu3akPdQfh1NIO DGwwX7Sz98YSwPVGW574J9RjjEIdqfM/XZ+mQ3GTrm1XkG1fd+weWW7nz 5W1KxeK7gnz7W0M9SC53L6uV3p7xFNOVEMowCjUE3Q1JOFc4pax0tqmqM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAA5Sr5b/5BdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmfygKg2uIFYw1gg2WfoF6CwEBGAu?= =?us-ascii?q?ESQIXhDkhNA0NAQMBAQIBAQJtHAyFOQEBAQECAQEBIRE6CxACAQgYAgIIHgI?= =?us-ascii?q?CAiULFRACBA4FgyEBgWkDDQgPphKBLoc3CIIYBYELijAXgUE/gRInH4JMgxs?= =?us-ascii?q?BAYFhF4JqMYImAohNNoZqjhkJApBPF4FPhGmDEIZDlWUCERSBJR04gVVwFTs?= =?us-ascii?q?qAYJBixeFPQFviz+BHwEB?= X-IronPort-AV: E=Sophos;i="5.54,365,1534809600"; d="scan'208";a="184138346" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2018 18:57:06 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w9AIv68D030656 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Oct 2018 18:57:06 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Oct 2018 14:57:05 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Wed, 10 Oct 2018 14:57:05 -0400 From: "Eric Vyncke (evyncke)" To: Paul Kyzivat CC: "clue@ietf.org" , "draft-ietf-clue-signaling.all@ietf.org" Thread-Topic: [clue] Opsdir last call review of draft-ietf-clue-signaling-13 Thread-Index: AQHUYMiH08twr3jQS0SLWwLftkcEWqUZORaA Date: Wed, 10 Oct 2018 18:57:05 +0000 Message-ID: References: <153919501667.5824.11176366846856816586@ietfa.amsl.com> <7f79eefb-0868-5fbd-8052-13e3d41ee98e@comcast.net> In-Reply-To: <7f79eefb-0868-5fbd-8052-13e3d41ee98e@comcast.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.245.206] Content-Type: text/plain; charset="utf-8" Content-ID: <5171F1E6A11D6047AB36CF66656E896B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [clue] Opsdir last call review of draft-ietf-clue-signaling-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:57:11 -0000 UGF1bA0KDQpUaGFuayB5b3UgZm9yIHRoZSBleHBsYW5hdGlvbiBhYm91dCB0aGUgbWlkZGxlIGJv eGVzLCB5b3UgbWF5IHdhbnQgdG8gcmVwZWF0IHRoaXMgdGV4dCBpZiB5b3UgbWFrZSBhIC0xNA0K DQotw6lyaWMNCg0K77u/T24gMTAvMTAvMjAxOCwgMjA6MzksICJQYXVsIEt5eml2YXQiIDxwYXVs Lmt5eml2YXRAY29tY2FzdC5uZXQ+IHdyb3RlOg0KDQogICAgw4lyaWMsDQogICAgDQogICAgT24g MTAvMTAvMTggMjoxMCBQTSwgw4lyaWMgVnluY2tlIHdyb3RlOg0KICAgID4gUmV2aWV3ZXI6IMOJ cmljIFZ5bmNrZQ0KICAgID4gUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCiAgICA+IA0KICAgID4g UmV2aWV3ZXI6IEVyaWMgVnluY2tlDQogICAgPiBSZXZpZXcgcmVzdWx0OiBoYXMgbWlub3Igbml0 cw0KICAgID4gDQogICAgPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9m IHRoZSBPcGVyYXRpb25hbCBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCiAgICA+IGVmZm9ydCB0byBy ZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRo ZXNlDQogICAgPiBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGltcHJv dmluZyB0aGUgb3BlcmF0aW9uYWwgYXNwZWN0cyBvZg0KICAgID4gdGhlIElFVEYgZHJhZnRzLiBD b21tZW50cyB0aGF0IGFyZSBub3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBtYXkgYmUgaW5jbHVk ZWQNCiAgICA+IGluIEFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIERvY3VtZW50 IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQNCiAgICA+IHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KICAgID4gDQogICAgPj5G cm9tIGEgZGVwbG95bWVudCBwb2ludCBvZiB2aWV3LCBJIGxpa2VkIHRoaXMgaW50cm9kdWN0aW9u IHN0YXRlbWVudA0KICAgID4gIkJhY2t3YXJkcy1jb21wYXRpYmlsaXR5IGlzIGFuIGltcG9ydGFu dCBjb25zaWRlcmF0aW9uIG9mIHRoZSBwcm90b2NvbDogaXQgaXMNCiAgICA+IHZpdGFsIHRoYXQg YSBDTFVFLWNhcGFibGUgZGV2aWNlIGNvbnRhY3RpbmcgYSBkZXZpY2UgdGhhdCBkb2VzIG5vdCBz dXBwb3J0IENMVUUNCiAgICA+IGlzIGFibGUgdG8gZmFsbCBiYWNrIHRvIGEgZnVsbHkgZnVuY3Rp b25hbCBub24tQ0xVRSBjYWxsLiIgQW5kIHNwZWNpYWwgY2FyZSBvZg0KICAgID4gY28tZXhpc3Rl bmNlIGR1cmluZyBkZXBsb3llbWVudCBhcHBlYXIgaW4gdGhlIGRvY3VtZW50Lg0KICAgIA0KICAg IFRoYW5rcy4gSXQgd2FzIGEgY3JpdGljYWwgcG9pbnQgZm9yIHVzIQ0KICAgIA0KICAgID4gQnV0 LCBJIHdvbmRlciBob3cNCiAgICA+ICptaWRkbGUgYm94ZXMqIHdvdWxkIHJlYWN0IGlmIHRoZXkg YXJlIG5vdCBhd2FyZSBvZiB0aGlzIHByb3RvY29sIGV4dGVuc2lvbi4NCiAgICANCiAgICBJbiBn ZW5lcmFsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGV4aXN0aW5nIG1pZGRsZSBib3hlcyB0byB1bmRl cnN0YW5kIGl0LiANCiAgICAgRnJvbSB0aGVpciBwZXJzcGVjdGl2ZSBjbHVlIG5lZ290aWF0aW9u cyBhcmUganVzdCBuZWdvdGlhdGlvbnMgb2Ygc2lwIA0KICAgIHNlc3Npb25zIHdpdGggbXVsdGlw bGUgbWVkaWEgc3RyZWFtcy4gVGhlIHVzZSBvZiBidW5kbGUgbWF5IGhhdmUgbW9yZSANCiAgICBp bXBhY3Qgb24gdGhlbSwgYnV0IHRob3NlIGlzc3VlcyBhcmUgZGVhbHQgd2l0aCBhcyBwYXJ0IG9m IHRoZSBidW5kbGUgc3BlYy4NCiAgICANCiAgICBNaWRkbGUgYm94ZXMgdGhhdCBhcmUgcmVzdHJp Y3RpdmUsIHN1Y2ggYXMgZm9yYmlkZGluZyBtdWx0aXBsZSBhdWRpbyBvciANCiAgICB2aWRlbyBz dHJlYW1zLCBtaWdodCBjYXVzZSB0cm91YmxlLiBCdXQgd2UgY2FuJ3QgZG8gYW55dGhpbmcgYWJv dXQgdGhhdC4NCiAgICANCiAgICBPZiBjb3Vyc2UgaXQgbWF5IGJlIHBvc3NpYmxlIHRvIGltYWdp bmUgYSBtaWRkbGUgYm94IHRoYXQgd2FudHMgdG8gZG8gDQogICAgc29tZXRoaW5nIHNwZWNpYWwg d2l0aCBjbHVlLCBidXQgaXQgd291bGQgbmVlZCB0byB1bmRlcnN0YW5kIGNsdWUgdG8gZG8gDQog ICAgdGhhdC4NCiAgICANCiAgICAJVGhhbmtzLA0KICAgIAlQYXVsDQogICAgDQogICAgW05vdGU6 IEkgb21pdHRlZCBvcHNkaXIgZnJvbSB0aGUgbWFpbGluZyBsaXN0IGluIG15IHJlcGx5IGluIA0K ICAgIGFudGljaXBhdGlvbiB0aGF0IGl0IHdvdWxkIGJlIHJlamVjdGVkIGJlY2F1c2UgSSBkb24n dCBzdWJzY3JpYmUgdG8gaXQuXQ0KICAgIA0KICAgID4gUGxlYXNlIGJlYXIgd2l0aCBteSB2ZXJ5 IGxpZ2h0IHVuZGVyc3RhbmRpbmcgb2YgQ0xVRSBpbiBnZW5lcmFsLiBBcyBhIHNpZGUNCiAgICA+ IG5vdGUsIGl0IHdvdWxkIGhhdmUgYmVlbiBuaWNlIHRvIGV4cGFuZCB0aGUgQ0xVRSBhY3Jvbnlt IHdoZW4gdXNlZCB0aGUgZmlyc3QNCiAgICA+IHRpbWUuIEluIGdlbmVyYWwsIHRoZSBkb2N1bWVu dCBpcyBub3QgZWFzeSB0byByZWFkOiB0b28gbWFueSBkZXRhaWxzIGdpdmVuDQogICAgPiBpbW1l ZGlhdGVseSB3aXRob3V0IGEgZmlyc3QgaGlnaC1sZXZlbCBkZXNjcmlwdGlvbi4gU28sIHRoZSBz ZWN0aW9ucyA4IGFuZCA5DQogICAgPiAoZXhhbXBsZXMpIGFyZSByZWFsbHkgdXNlZnVsIGV2ZW4g aWYgbW9yZSBkZXRhaWxzIGNvdWxkIGhhdmUgYmVlbiBnaXZlbjogZm9yDQogICAgPiBleGFtcGxl LCB3aGlsZSB0aGUgaW5pdGlhbCBTRFAgaXMgc2hvd24sIHRoZSByZXNwb25zZSBTRFAgaXMgbm90 Lg0KICAgID4gDQogICAgPiBOaXRzOiBzZWN0aW9uIDYgaGFzIGEgcmVmZXJlbmNlIHdoaWNoIGRv ZXMgbm90IGhhdmUgYSBVUkkuDQogICAgPiANCiAgICA+IEVsc2UsIHRoaXMgZG9jdW1lbnQgaXMg cmVhZHkgdG8gZ28uDQogICAgPiANCiAgICA+IC3DqXJpYw0KICAgID4gDQogICAgPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gY2x1ZSBtYWls aW5nIGxpc3QNCiAgICA+IGNsdWVAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KICAgID4gDQogICAgDQogICAgDQoNCg== From nobody Wed Oct 10 15:43:13 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FD1130DFF; Wed, 10 Oct 2018 15:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 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, 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 fvmZKqu62iv6; Wed, 10 Oct 2018 15:43:00 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC11F12F18C; Wed, 10 Oct 2018 15:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5058; q=dns/txt; s=iport; t=1539211379; x=1540420979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vIhq8eP8YtxHqEc8XrL254ffxdpM9ZjwP59m6Az+uR4=; b=feW4EUiQ7h6I4CS6LjLfoeKZb24oO/coA1C05gbJmuqSD/5Mx5IavcuX ghfdTs2QuXhSqNk1waZFgYv3ondc9zK/ULdp0aLkMp8IMqBXwOYxKCY6Q HdLpfpMDu7/66Xil6lLhOA9x3WNeOsDjDleAFVKvyLVTQz8NSf03VHSuN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAAADgL5b/51dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmfygKg2uIFow2gg2DP5NAgXoLAQE?= =?us-ascii?q?YC4RJAheEOSE0DQ0BAwEBAgEBAm0cDIU5AQEBAQIBAQEhEToLDAQCAQgRBAE?= =?us-ascii?q?BAQICCB4CAgIlCxUICAIEAQ0FCIMagWkDDQgPpiGBLoc7CIIYBYELijCCF4E?= =?us-ascii?q?SgxKDGwEBgXiCaoJXAoEoAYckNoZqjhkGAwKQRx+BT4RpgxCGQ4kTjFICERS?= =?us-ascii?q?BJR04gVVwUIEegU6LF4U9AW+MRoEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,366,1534809600"; d="scan'208";a="183609263" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2018 22:42:47 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w9AMglfD021703 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Oct 2018 22:42:47 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Oct 2018 17:42:47 -0500 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1395.000; Wed, 10 Oct 2018 17:42:46 -0500 From: "Rob Hanton (rohanse2)" To: "Eric Vyncke (evyncke)" , Paul Kyzivat CC: "clue@ietf.org" , "draft-ietf-clue-signaling.all@ietf.org" Thread-Topic: [clue] Opsdir last call review of draft-ietf-clue-signaling-13 Thread-Index: AQHUYMSD3i/Fe8OzvEayU1yQH3ulm6UZI1IAgAAFCYD//+r5kA== Date: Wed, 10 Oct 2018 22:42:46 +0000 Message-ID: References: <153919501667.5824.11176366846856816586@ietfa.amsl.com> <7f79eefb-0868-5fbd-8052-13e3d41ee98e@comcast.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.136.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [clue] Opsdir last call review of draft-ietf-clue-signaling-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 22:43:11 -0000 SSdtIHBhcnQtd2F5IHRocm91Z2ggYSAtMTQgdXBkYXRlIGFuZCB3aWxsIGVuc3VyZSBJIHJldmll dyB0aGUgdmFyaW91cyBpc3N1ZXMgeW91IHJhaXNlIC0gdGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhl IHJldmlldy4NCg0KUm9iDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjbHVl IDxjbHVlLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBFcmljIFZ5bmNrZSAoZXZ5bmNr ZSkNClNlbnQ6IDEwIE9jdG9iZXIgMjAxOCAxOTo1Nw0KVG86IFBhdWwgS3l6aXZhdCA8cGF1bC5r eXppdmF0QGNvbWNhc3QubmV0Pg0KQ2M6IGNsdWVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2x1ZS1z aWduYWxpbmcuYWxsQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NsdWVdIE9wc2RpciBsYXN0IGNh bGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2x1ZS1zaWduYWxpbmctMTMNCg0KUGF1bA0KDQpUaGFu ayB5b3UgZm9yIHRoZSBleHBsYW5hdGlvbiBhYm91dCB0aGUgbWlkZGxlIGJveGVzLCB5b3UgbWF5 IHdhbnQgdG8gcmVwZWF0IHRoaXMgdGV4dCBpZiB5b3UgbWFrZSBhIC0xNA0KDQotw6lyaWMNCg0K 77u/T24gMTAvMTAvMjAxOCwgMjA6MzksICJQYXVsIEt5eml2YXQiIDxwYXVsLmt5eml2YXRAY29t Y2FzdC5uZXQ+IHdyb3RlOg0KDQogICAgw4lyaWMsDQogICAgDQogICAgT24gMTAvMTAvMTggMjox MCBQTSwgw4lyaWMgVnluY2tlIHdyb3RlOg0KICAgID4gUmV2aWV3ZXI6IMOJcmljIFZ5bmNrZQ0K ICAgID4gUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCiAgICA+IA0KICAgID4gUmV2aWV3ZXI6IEVy aWMgVnluY2tlDQogICAgPiBSZXZpZXcgcmVzdWx0OiBoYXMgbWlub3Igbml0cw0KICAgID4gDQog ICAgPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBPcGVyYXRp b25hbCBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCiAgICA+IGVmZm9ydCB0byByZXZpZXcgYWxsIElF VEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQogICAgPiBj b21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGltcHJvdmluZyB0aGUgb3Bl cmF0aW9uYWwgYXNwZWN0cyBvZg0KICAgID4gdGhlIElFVEYgZHJhZnRzLiBDb21tZW50cyB0aGF0 IGFyZSBub3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBtYXkgYmUgaW5jbHVkZWQNCiAgICA+IGlu IEFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIERvY3VtZW50IGVkaXRvcnMgYW5k IFdHIGNoYWlycyBzaG91bGQNCiAgICA+IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBh bnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KICAgID4gDQogICAgPj5Gcm9tIGEgZGVwbG95 bWVudCBwb2ludCBvZiB2aWV3LCBJIGxpa2VkIHRoaXMgaW50cm9kdWN0aW9uIHN0YXRlbWVudA0K ICAgID4gIkJhY2t3YXJkcy1jb21wYXRpYmlsaXR5IGlzIGFuIGltcG9ydGFudCBjb25zaWRlcmF0 aW9uIG9mIHRoZSBwcm90b2NvbDogaXQgaXMNCiAgICA+IHZpdGFsIHRoYXQgYSBDTFVFLWNhcGFi bGUgZGV2aWNlIGNvbnRhY3RpbmcgYSBkZXZpY2UgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IENMVUUN CiAgICA+IGlzIGFibGUgdG8gZmFsbCBiYWNrIHRvIGEgZnVsbHkgZnVuY3Rpb25hbCBub24tQ0xV RSBjYWxsLiIgQW5kIHNwZWNpYWwgY2FyZSBvZg0KICAgID4gY28tZXhpc3RlbmNlIGR1cmluZyBk ZXBsb3llbWVudCBhcHBlYXIgaW4gdGhlIGRvY3VtZW50Lg0KICAgIA0KICAgIFRoYW5rcy4gSXQg d2FzIGEgY3JpdGljYWwgcG9pbnQgZm9yIHVzIQ0KICAgIA0KICAgID4gQnV0LCBJIHdvbmRlciBo b3cNCiAgICA+ICptaWRkbGUgYm94ZXMqIHdvdWxkIHJlYWN0IGlmIHRoZXkgYXJlIG5vdCBhd2Fy ZSBvZiB0aGlzIHByb3RvY29sIGV4dGVuc2lvbi4NCiAgICANCiAgICBJbiBnZW5lcmFsIHRoZXJl IGlzIG5vIG5lZWQgZm9yIGV4aXN0aW5nIG1pZGRsZSBib3hlcyB0byB1bmRlcnN0YW5kIGl0LiAN CiAgICAgRnJvbSB0aGVpciBwZXJzcGVjdGl2ZSBjbHVlIG5lZ290aWF0aW9ucyBhcmUganVzdCBu ZWdvdGlhdGlvbnMgb2Ygc2lwIA0KICAgIHNlc3Npb25zIHdpdGggbXVsdGlwbGUgbWVkaWEgc3Ry ZWFtcy4gVGhlIHVzZSBvZiBidW5kbGUgbWF5IGhhdmUgbW9yZSANCiAgICBpbXBhY3Qgb24gdGhl bSwgYnV0IHRob3NlIGlzc3VlcyBhcmUgZGVhbHQgd2l0aCBhcyBwYXJ0IG9mIHRoZSBidW5kbGUg c3BlYy4NCiAgICANCiAgICBNaWRkbGUgYm94ZXMgdGhhdCBhcmUgcmVzdHJpY3RpdmUsIHN1Y2gg YXMgZm9yYmlkZGluZyBtdWx0aXBsZSBhdWRpbyBvciANCiAgICB2aWRlbyBzdHJlYW1zLCBtaWdo dCBjYXVzZSB0cm91YmxlLiBCdXQgd2UgY2FuJ3QgZG8gYW55dGhpbmcgYWJvdXQgdGhhdC4NCiAg ICANCiAgICBPZiBjb3Vyc2UgaXQgbWF5IGJlIHBvc3NpYmxlIHRvIGltYWdpbmUgYSBtaWRkbGUg Ym94IHRoYXQgd2FudHMgdG8gZG8gDQogICAgc29tZXRoaW5nIHNwZWNpYWwgd2l0aCBjbHVlLCBi dXQgaXQgd291bGQgbmVlZCB0byB1bmRlcnN0YW5kIGNsdWUgdG8gZG8gDQogICAgdGhhdC4NCiAg ICANCiAgICAJVGhhbmtzLA0KICAgIAlQYXVsDQogICAgDQogICAgW05vdGU6IEkgb21pdHRlZCBv cHNkaXIgZnJvbSB0aGUgbWFpbGluZyBsaXN0IGluIG15IHJlcGx5IGluIA0KICAgIGFudGljaXBh dGlvbiB0aGF0IGl0IHdvdWxkIGJlIHJlamVjdGVkIGJlY2F1c2UgSSBkb24ndCBzdWJzY3JpYmUg dG8gaXQuXQ0KICAgIA0KICAgID4gUGxlYXNlIGJlYXIgd2l0aCBteSB2ZXJ5IGxpZ2h0IHVuZGVy c3RhbmRpbmcgb2YgQ0xVRSBpbiBnZW5lcmFsLiBBcyBhIHNpZGUNCiAgICA+IG5vdGUsIGl0IHdv dWxkIGhhdmUgYmVlbiBuaWNlIHRvIGV4cGFuZCB0aGUgQ0xVRSBhY3JvbnltIHdoZW4gdXNlZCB0 aGUgZmlyc3QNCiAgICA+IHRpbWUuIEluIGdlbmVyYWwsIHRoZSBkb2N1bWVudCBpcyBub3QgZWFz eSB0byByZWFkOiB0b28gbWFueSBkZXRhaWxzIGdpdmVuDQogICAgPiBpbW1lZGlhdGVseSB3aXRo b3V0IGEgZmlyc3QgaGlnaC1sZXZlbCBkZXNjcmlwdGlvbi4gU28sIHRoZSBzZWN0aW9ucyA4IGFu ZCA5DQogICAgPiAoZXhhbXBsZXMpIGFyZSByZWFsbHkgdXNlZnVsIGV2ZW4gaWYgbW9yZSBkZXRh aWxzIGNvdWxkIGhhdmUgYmVlbiBnaXZlbjogZm9yDQogICAgPiBleGFtcGxlLCB3aGlsZSB0aGUg aW5pdGlhbCBTRFAgaXMgc2hvd24sIHRoZSByZXNwb25zZSBTRFAgaXMgbm90Lg0KICAgID4gDQog ICAgPiBOaXRzOiBzZWN0aW9uIDYgaGFzIGEgcmVmZXJlbmNlIHdoaWNoIGRvZXMgbm90IGhhdmUg YSBVUkkuDQogICAgPiANCiAgICA+IEVsc2UsIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgdG8gZ28u DQogICAgPiANCiAgICA+IC3DqXJpYw0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gY2x1ZSBtYWlsaW5nIGxpc3QNCiAg ICA+IGNsdWVAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2x1ZQ0KICAgID4gDQogICAgDQogICAgDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo= From nobody Fri Oct 12 08:14:32 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8C2130E77 for ; Fri, 12 Oct 2018 08:14:09 -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 Q1uLE88wJAMS for ; Fri, 12 Oct 2018 08:14:06 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 A9009130E2A for ; Fri, 12 Oct 2018 08:13:58 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id y144-v6so13213969wmd.4 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=m1NurmFh5DlJG51vD6cslwzr4GVU5mCbglCgrMKnXynQVWH1lRztYXCLDcFL1UjFkN QPmjqXA4JeXsC5Do6YlGLeIJ8PKj0SzFs6lUJbO9IP+K0cCtYgJi4tG0qnj/DI6XOaJq nPybPRKDvDIJ6fvJo0SZ2etNXSMo/cJ9b+nSisHnVOzZQxmFWS+04pXE2SGHl5M/dZqy DgaKXooD/fWLuTN84D7cBLHsmYjkptzwwHEGMpYBddhGrqGimpNQIrZt0FJxKnVj6MaU Z2ErfW7ij27R5k3ThRYLpzsABNOrlUKO85hiFea3mO8DeU7AhElLJ5bwjk9URDuHV4Sc NBvg== X-Gm-Message-State: ABuFfoj6TGFz8tLs8lSGVJemGAdUKxWpbOu2VnuOltKn9tRNn1fKY1W2 efBDccSjkYFUUj9AXPuoslg6DPei5MJcYX9qPL/9Qw== 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: [clue] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 15:14:21 -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 13:23:13 2018 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 416D0126DBF; Fri, 12 Oct 2018 13:23:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: clue@ietf.org, ietf@ietf.org, draft-ietf-clue-signaling.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153937578523.29131.6059409977356664633@ietfa.amsl.com> Date: Fri, 12 Oct 2018 13:23:05 -0700 Archived-At: Subject: [clue] Genart last call review of draft-ietf-clue-signaling-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 20:23:05 -0000 Reviewer: Robert Sparks Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-clue-signaling-13 Reviewer: Robert Sparks Review Date: 2018-10-12 IETF LC End Date: 2018-10-17 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as PS with nits This document specifies a specific ASN.1 Identifier for sip.clue (see section 11.2). Did you go through some kind of early reservation process for this? If not, you've gotten very lucky that something else didn't step on the value. There are several places where the document uses SHOULD where it's not immediately clear why it didn't use MUST. Some of those SHOULDs are probably better written around with prose. For example, in the first paragraph of 4.5.1, I think you're trying say "If the CLUE capable device wants to use CLUE it will..." The MUST in the last paragraph of section 4.5.4.4 is probably also better as "will". There are lots of other reasons for a device to discontinue media. As written, this is oddly overconstraining. The "MAY or MAY NOT" at the end of 7.1 is a bad use of 2119. Lower case versions of the word here will not introduce protocol ambiguity. Section 7.2 says this specification imposes no additional constraints on the usage of BUNDLE, but then goes on to aplly a MUST NOT in 7.2.1. This is another place where you probably want to avoid 2119, and instead say "don't do this if you want to avoid inefficiency". "O/A" appears without definition at the top of page 20. I did not review the bits in the examples carefully. From nobody Fri Oct 12 18:08:50 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344C5130E96 for ; Fri, 12 Oct 2018 18:08:47 -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 IDvlCY7BCuAs for ; Fri, 12 Oct 2018 18:08:44 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 ABD83128766 for ; Fri, 12 Oct 2018 18:08:44 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id c23-v6so21350935itd.5 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=cm7Lpn8b9ST9haKKhbEtNA1anB5pQyrl0ZdCj7c5F+5FSEl/SOBE9mqB5xIcDIHW8p Kudzl0i04vjzJEMeluNSnfBs33KVW8IPniusQR/N0jFgYOrhIQSJQ3eJhMMBWtOKYtgT MRLQgcmmFLvGb/B88mlN3AG9mYd60RhHuTuQSqtbWvJ5E4khrTl6pUvEkK1lw57IBjGZ JPd2rhLpOzW/UM70heaDRCAi5NR18XH/EjPUjzaz8gF9v3lw6+6wxioX6YT83PBamwXH o5dx6HZsCB4kPtIrTXzQmhdupFWFQbEjzD9xowUg956aMnHRT2MwKmBzRMlu4jatGNGV 8rcQ== X-Gm-Message-State: ABuFfohBErF6LZCgIdN5JUdm8Eq1lL28XCV55/9ZIYFOWTprCCe3g+gS FMeZ7vQmcEMehTA1e+FFjCkvviwpP+Cj3XqOHIq3rQ== 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: [clue] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 01:08:47 -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:15 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@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: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence 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 Sun Oct 14 11:29:51 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AECC130DDB for ; Sat, 13 Oct 2018 02:51:58 -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=unavailable 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 RJF3ERb8QzOU for ; Sat, 13 Oct 2018 02:51:56 -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 74D2A130EC6 for ; Sat, 13 Oct 2018 02:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=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: Sun, 14 Oct 2018 11:29:50 -0700 Subject: Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster 238 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 09:51:58 -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

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 Tue Oct 16 17:09:29 2018 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D72F130E65 for ; Tue, 16 Oct 2018 17:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6yA_fcJ29Ps for ; Tue, 16 Oct 2018 17:09:25 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91779126BED for ; Tue, 16 Oct 2018 17:09:25 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id v69-v6so19663600oif.1 for ; Tue, 16 Oct 2018 17:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mWnq4bABILlC1PG1/Bxf3pgrDcFXQGopgnesIteBhmU=; b=FDWI5mXzVLChSTN3K7+oO+OQxn7KNtZVEOOyExXq87RQD6aCuDxCqRzf4tr4lPVK3B a9UcQEqZspmCOb9/nZcTaH+ujrCn5BS8T7gk++W3g3VHRxSjFkwiXBmiI7ExoCUtyffh /AVKk46q2bsYNumvhu1taGSnMzF6qAbVhGRokp9oVa2h1lxH+OsO4UaOrXX3+0qBw7h4 +i8XnjoGXG4hm9XSLB/bUj/bHazaUGXmJi7RCTAAhXhCEdZwceJTzg2PVPM8KlO3S4n1 tjoKIOEA1WaYSCeKhdgpJDNlZLw2Oh9BlUZisrQvwSMRl2q26GSoWdzEOM7SSdSfx25G qnHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mWnq4bABILlC1PG1/Bxf3pgrDcFXQGopgnesIteBhmU=; b=CC28PyBz8X2pNsp06dDR0eeR3bzCAqimztNItMDSqjd18dNf2cCFceqvk5vMbPAc/T teix125h13TNGNUpXcDtZBls3j4Op35AOIjuW2yoF0VfCBNQCp9LXluI9UmQ3a1CJLUW DBmbxeleZPT4diQD6kPYndDtYUW3TQSayonDmFnVyTHaEz0Y2GQy1tkBwVknRl0CSFu0 gQZBhZSR/VRYstLaGqFAI/SOGWItx3sAlS5Q4FggsPvxI9/SCEwIMHZRiZrFylqRf/KG gRjiINziutFtA1prowTFli+2uO5CtiggqmPvz2eiYyl12X/G/mYGr/gFnugjtDx5qd52 NU3g== X-Gm-Message-State: ABuFfoiPYzs93F6vQFl8wbXSHx1efSBMX7PE+yJA7k+YK2hZUgu5ZfBz aXpbn6vtpwGiPkfwXkWGFVY2NF3ISU82n6KYWJucZNV80mM= X-Google-Smtp-Source: ACcGV61vWa6zGgDDt83Ly1ipXBche4EpQdocUo3hxDJ6xPw/icqEjuV/j2DrWpgGazNQmfR6DlF9fwgDOBs3UZz7+qg= X-Received: by 2002:aca:de46:: with SMTP id v67-v6mr13396114oig.167.1539734964700; Tue, 16 Oct 2018 17:09:24 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Wed, 17 Oct 2018 11:09:14 +1100 Message-ID: To: clue@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [clue] XML review of draft-ietf-clue-protocol-17 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 00:09:27 -0000 I was asked to provide expert review of the registrations for the XML schema in this document and noticed a few problems. I also have a few suggestions. 1. Don't use schemaLocation in this document, especially in the schema, but also in examples 2. Please try to be more consistent with prefixes throughout. The namespace defined in the draft is sometimes given no prefix, sometimes the overly generic "ns2". I appreciate that these are generated examples, but more thought needs to be given to that. In particular, the schema assigns two different prefixes to the same namespace. 3. This definition is useless: All that a definition like this does is force people to waste bytes. The namespace is sufficient to identify the protocol. Use of fixed and required attributes is best left to restrictions of complex types. 4. You can add the attribute extension point to the base message definition. Element extensions unfortunately have to be attached to specific message types for ordering reasons, but attributes are unordered. 5. Consider vertical whitespace in your code. It helps readability considerably. From nobody Wed Oct 17 11:27:22 2018 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E959130DEF; Wed, 17 Oct 2018 11:27:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Aanchal Malhotra To: Cc: clue@ietf.org, ietf@ietf.org, draft-ietf-clue-protocol.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153980082742.27596.4827797666040033929@ietfa.amsl.com> Date: Wed, 17 Oct 2018 11:27:07 -0700 Archived-At: Subject: [clue] Secdir last call review of draft-ietf-clue-protocol-17 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 18:27:07 -0000 Reviewer: Aanchal Malhotra Review result: Not Ready Reviewer: Aanchal Malhotra. Review Result: Ready Two points: 1) The Security Considerations section of the draft-ietf-clue-protocol mostly references back to the I-D.ietf-clue-framework, I-D.ietf-clue-data-model-schema and I-D.ietf-clue-datachannel. So the fate of this document depends on the approval of all other CLUE related documents that it references. 2) Clarification: There is one new threat introduced in the security considerations section of this document whose proposed solution is not clear to me. Following is the text: "...In theory an implementation could choose not to announce all of the versions it supports if it wants to avoid such leakage, though at the expenses of interoperability. With respect to the above considerations, it is noted that the OPTIONS state is only reached after the CLUE data channel has been successfully set up. This ensures that only authenticated parties can exchange 'options' and related 'optionsResponse' messages and hence drastically reduces the attack surface which is exposed to malicious parties." Question: If a participant CP1 does not announce all of the versions it supports to CP2, does not that imply the same threat/attack from CP1 that you are trying to avoid from CP2? In other words, CP1 could force CP2 to use a non-up-to-date version of the protocol or the one that it knows how to break. Am I missing something here? From nobody Mon Oct 22 13:45:56 2018 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A033130E99; Mon, 22 Oct 2018 13:45:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: clue@ietf.org Message-ID: <154024113847.13484.9566516756106638923@ietfa.amsl.com> Date: Mon, 22 Oct 2018 13:45:38 -0700 Archived-At: Subject: [clue] I-D Action: draft-ietf-clue-signaling-14.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 20:45:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence WG of the IETF. Title : Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) Authors : Robert Hanton Paul Kyzivat Lennard Xiao Christian Groves Filename : draft-ietf-clue-signaling-14.txt Pages : 42 Date : 2018-10-22 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-clue-signaling-14 https://datatracker.ietf.org/doc/html/draft-ietf-clue-signaling-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 31 12:31:54 2018 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCC11277C8; Wed, 31 Oct 2018 12:31:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-clue-protocol@ietf.org, "Daniel C. Burnett" , Paul Kyzivat , clue-chairs@ietf.org, pkyzivat@alum.mit.edu, clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154101430593.5389.2663125960619308709.idtracker@ietfa.amsl.com> Date: Wed, 31 Oct 2018 12:31:45 -0700 Archived-At: Subject: [clue] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?clue-protocol-17=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 19:31:46 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-clue-protocol-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document does not discuss any interactions with the transport protocol (e.g. who establishes the connection? what happens if the connections breaks; who should re-establish?). Also, I assume that SCTP is used (instead of TCP) because the idea is to use different SCTP streams for the different directions of the communication...? However, this is a complete guess, as the document does unfortunately not say nothing about the mapping of CLUE messages to SCTP sessions. In case all message are assumed to be send over the same stream instead, why is SCTP used and not TCP? Please provide more information and guidance on the use of SCTP! ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two minor editorial commets: 1) In the terminology section: What does MCU actually stand for? 2) sec 4: "CLUE protocol version numbers are characterized by a major version number (single digit) and a minor version number (single digit)..." However, later on the text says that the numbers can also consist of multiple digits... From nobody Wed Oct 31 12:38:14 2018 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4894A129C6A; Wed, 31 Oct 2018 12:38:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-clue-protocol@ietf.org, "Daniel C. Burnett" , Paul Kyzivat , clue-chairs@ietf.org, pkyzivat@alum.mit.edu, clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154101469022.5381.16886599582364654562.idtracker@ietfa.amsl.com> Date: Wed, 31 Oct 2018 12:38:10 -0700 Archived-At: Subject: [clue] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-clue-protocol-17=3A_=28with_COMMENT=29?= X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 19:38:10 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-clue-protocol-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Update: Revising my discuss, as I missed the pointer to draft-ietf-clue-signaling. Sorry for that! Two minor editorial commets: 1) In the terminology section: What does MCU actually stand for? 2) sec 4: "CLUE protocol version numbers are characterized by a major version number (single digit) and a minor version number (single digit)..." However, later on the text says that the numbers can also consist of multiple digits...