From nobody Thu Jun 1 01:24:46 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CF0129B61 for ; Thu, 1 Jun 2017 01:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdyCF0BRHwNG for ; Thu, 1 Jun 2017 01:24:43 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DAF129512 for ; Thu, 1 Jun 2017 01:24:42 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id h4so45273881oib.3 for ; Thu, 01 Jun 2017 01:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=sbFkHJCn5tawK7zpe1+F36B5wldgs0h56pgn/CNv8VA=; b=S5EB/bTweAZzpXNbO2SyqeAuxY/bMVCtvldcPv9WY5M/dy2wiN5s0eSz7OSEW93e0C xFVNnFyGSA4W7nfAW66UPtUBRPwaNuuGGUHsflczkk096fHWsZ2sVDFhM1hpMktjJ/c6 fGFUU3Pa++zi2RQD1DL/0E70Zhsg/oTx/64e2OA72GyBgW86uRlCGxbvX+qDyWcHZevI cAktWN5IbQrbMkQWRPjPBsSIc66wZQ+8zVy4+oCjcYxBmBQDWsDuNxVKebpuLOmp1l9y HQUGnitOeIK8Zpzqh6P0/PCEQwge192FjfFhqCK4Rz3xUvO7asq47yNeGIb0J2wYifkB OhXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=sbFkHJCn5tawK7zpe1+F36B5wldgs0h56pgn/CNv8VA=; b=th/Xa6dXBMQhTOr1AwhgGEZlFc97yglzcuPYhHQcUugHbnvqHekJzZDncSJ/MRue2U RG/C5iShu1oxLclFAELe0u/EZFZW6oiLEB7jbZf8aq49RnKgQSDrOjM8BL4u+4WFsRrx CHUVKTTF8Ezktml3zcK7EIIW/8u67z++CmCuF+A1nlgZ5lt+WDqghWMsUhgWUl/wq4HH AJWMP4EMfrrcILyWSqoNkJeLUNCaWxrC3rT7IyKMytFt/zYLCkws+5ynOUxBBUoQ/8yr uMw9zYD7APFPXUp9+RwZmNIWKWyEGeldH6GImkONKdQtJtIMLx1wDhQRhoPKGYFvDhkT fGVw== X-Gm-Message-State: AODbwcAAeyVUKAELbzynoQ+zeMW753hrscVKbCsf/McE3fN+0/Rlwbib u5OJeTYEr8qdBRdAhKJltL86JnribnDC X-Received: by 10.202.222.70 with SMTP id v67mr151298oig.88.1496305482142; Thu, 01 Jun 2017 01:24:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.73.148 with HTTP; Thu, 1 Jun 2017 01:24:21 -0700 (PDT) In-Reply-To: References: <149560430512.28459.18017801020136502401@ietfa.amsl.com> From: Barry Dingle Date: Thu, 1 Jun 2017 18:24:21 +1000 Message-ID: To: Justin Uberti , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a113ce978bd2d840550e1c476" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 08:24:45 -0000 --001a113ce978bd2d840550e1c476 Content-Type: text/plain; charset="UTF-8" The start of Section 3 of draft-ietf-rtcweb-fec-05.txt says: "By its name, FEC describes ...." The words 'By its name' are not needed. I suggest they be removed. Barry Dingle Melbourne, Australia On Thu, May 25, 2017 at 9:59 AM, Justin Uberti wrote: > Note that is simply a version bump for freshness. > > On Tue, May 23, 2017 at 10:38 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Real-Time Communication in WEB-browsers >> of the IETF. >> >> Title : WebRTC Forward Error Correction Requirements >> Author : Justin Uberti >> Filename : draft-ietf-rtcweb-fec-05.txt >> Pages : 10 >> Date : 2017-05-23 >> >> Abstract: >> This document provides information and requirements for how Forward >> Error Correction (FEC) should be used by WebRTC applications. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-rtcweb-fec-05 >> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-05 >> >> >> 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/ >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113ce978bd2d840550e1c476 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The start of Section 3 of draft-ietf-rtcweb-fec-05.tx= t says: "By its name, FEC describes ...."

The words = 'By its name' are not needed. I suggest they be removed.

Barry Dingle
Melbourne, Australia
<= /div>

On Thu, May 25, 2017 at 9:59 AM, Justin Uber= ti <juberti@google.com> wrote:
Note that is simply a version bum= p for freshness.
<= div class=3D"gmail_extra">
On Tue, May 23, 20= 17 at 10:38 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-05-23

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-rtcweb-fec/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcw= eb-fec-05
https://datatracker.ietf.org/doc/= html/draft-ietf-rtcweb-fec-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-rtcweb-fec-05


Please note that it may take a couple of minutes from the time of submissio= n
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/

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


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

--001a113ce978bd2d840550e1c476-- From nobody Fri Jun 2 03:08:33 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F1E129512; Fri, 2 Jun 2017 03:08:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: adam@nostrum.com, rtcweb@ietf.org, sean@sn3rd.com, rtcweb-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149639811155.31792.15361397611817498856.idtracker@ietfa.amsl.com> Date: Fri, 02 Jun 2017 03:08:31 -0700 Archived-At: Subject: [rtcweb] rtcweb - New Meeting Session Request for IETF 99 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 10:08:31 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the rtcweb working group. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: perc sipcore payload mmusic acme stir httpbis dispatch clue avtext avtcore aqm rmcat tls quic Second Priority: dprive tcpinc tsvwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen opsawg People who must be present: Eric Rescorla Sean Turner Adam Roach Cullen Jennings Martin Thomson Alissa Cooper Ted Hardie Justin Uberti Harald Alvestrand Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 2 03:45:04 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0C1126BF0 for ; Fri, 2 Jun 2017 03:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQMlLt18gDn6 for ; Fri, 2 Jun 2017 03:45:01 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5071200F1 for ; Fri, 2 Jun 2017 03:45:01 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id r63so15274869itc.1 for ; Fri, 02 Jun 2017 03:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=LRFoTAi+844Gq1rkYv2D8QguNG85r1aJaTNNLPtpfW8=; b=H332QrD4XjNUwf8O8j7u5wGIP3fBypu34vpzCnH0YZbENtTj6kFKUkSYeqR/jajFGC 2sIQF48QhGEUKFYPVKH44wRSzz8vgDUVFIrrDspD6shwD/sFo0UwiTKgsIZvTt/l5294 17RIglYOcxPhTeojqvX1eMhGvnS3k/fxQGESM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=LRFoTAi+844Gq1rkYv2D8QguNG85r1aJaTNNLPtpfW8=; b=I93rh6KlY2IubB/7RtiM1CUeSRa3SYE2wyqJ9QDkqFTo4FP8Qv1NvB4zpfRo00TgSz 657PuJUdKJS3pBRCwlGQFG+XnTlRD7qmi2OJLw9WLsppfsARsCodzTD6A7pb2psoR1tB a7bqTKLx6NR4s/68kcmrfQqrqFZT5HkhPCSIlO1v5ex8FFUJt7f6Be05yWKDxrHZLaGv aiDvEWR40/YI5FvCBLE1qPaWhffDzNye4KVQY6LDYB3gWEQVPZwlxgkz1TytI9oOi/5u GZC0CmAPvtJ9RlMWubesZ2mpm9vFurTUDI4QNa5fHWsgTfXljbpzDDxGFk2E3FMCxJDY Vm+Q== X-Gm-Message-State: AODbwcB0s/nXjc1d57gpyThAgOps3mlfHtkiWj6vWLsRuLHCVHYOyQ9I ZllV28429MhDmU52n2dPPA== X-Received: by 10.36.238.69 with SMTP id b66mr3714455iti.54.1496400300143; Fri, 02 Jun 2017 03:45:00 -0700 (PDT) Received: from [5.5.33.138] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id 74sm878489itj.15.2017.06.02.03.44.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 03:44:59 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 2 Jun 2017 06:44:54 -0400 References: <149639811155.31792.15361397611817498856.idtracker@ietfa.amsl.com> To: RTCWeb IETF In-Reply-To: <149639811155.31792.15361397611817498856.idtracker@ietfa.amsl.com> Message-Id: <3481B37D-C079-4FA1-8A2B-FD52877E8F5D@sn3rd.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] rtcweb - New Meeting Session Request for IETF 99 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 10:45:03 -0000 I=E2=80=99ve gone ahead and schedule a session that is intended to be = used for review of the hopefully revised security drafts. spt > On Jun 2, 2017, at 06:08, IETF Meeting Session Request Tool = wrote: >=20 >=20 >=20 > A new meeting session request has just been submitted by Sean Turner, = a Chair of the rtcweb working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Real-Time Communication in WEB-browsers > Area Name: Applications and Real-Time Area > Session Requester: Sean Turner >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 70 From nobody Fri Jun 2 06:40:24 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB6812EBAF for ; Fri, 2 Jun 2017 06:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 rurn_X7jnJrh for ; Fri, 2 Jun 2017 06:40:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2875212EBB3 for ; Fri, 2 Jun 2017 06:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5597; q=dns/txt; s=iport; t=1496410821; x=1497620421; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=mBRLrXndoE46V1P3e9pB+vhnc6zRqDc/XnhoQkPINB0=; b=QZOhVa73OkzSTRVcnYSMYsczwjAAQSlJxP2BE+5n5kDKAIt4K4ojgsj9 HFHHVG0Pr9TkoJ5h8tN386sWLxRn+DH9WCQ9oZrDLf0FkaxvDH6B8+oAD UnXSJ+CMvenIa9voSKOLZRMHPIZ9eQf1D/Npy8YhzsYEgcGflkrtsGRvp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AAB0ajFZ/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyotYoENg3OKGZF5iCmNU4IPIQ2FLEoCgns/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAwEBIQ8BBTYLEAsOAwQBAQECAiMDAgIhBh8JCAYBDAYCAQGKDgMID?= =?us-ascii?q?RACrnSCJocyDYQRAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VWgWArgnSCWIU?= =?us-ascii?q?kgmABBJ10O4chgzaDfIRYggaFPINKI4ZLizuJIR84gQpRIxVGhQYcgX8kNolzA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.39,285,1493683200"; d="scan'208";a="252792004" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2017 13:40:02 +0000 Received: from [10.118.10.22] (rtp-fandreas-2-8815.cisco.com [10.118.10.22]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v52De1qO007225; Fri, 2 Jun 2017 13:40:01 GMT To: Cullen Jennings , Christer Holmberg References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> Cc: RTCWeb IETF , "mmusic-chairs@tools.ietf.org" From: Flemming Andreasen Message-ID: <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> Date: Fri, 2 Jun 2017 09:40:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 13:40:23 -0000 Please note that we have several drafts in MMUSIC that normatively reference 5245bis, and some of those drafts are RTCWeb dependencies AFAIK. Thanks -- Flemming (as MMUSIC co-chair) On 5/22/17 6:52 PM, Cullen Jennings wrote: > Note that I don't think the timeline is the major issue (it is an issue) ... they key issue is that 5245bis does not seem to be needed for any technical reason by WebRTC. > > >> On May 18, 2017, at 11:03 AM, Christer Holmberg wrote: >> >> Hi, >> >> >> >> In general, if people have issues with referencing 5245bis because they are afraid it will hold up publication of RTCWEB specs, note that I have indicated to the ICE WG chairs that I think 5245bis is getting ready for WGLC. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba >> Sent: 18 May 2017 18:50 >> To: Sean Turner >> Cc: RTCWeb IETF >> Subject: Re: [rtcweb] Referring to 5245bis or 5245? >> >> >> >> Sean said: >> >> >> >> "draft-ietf-rtcweb-transports: Likewise, the chairs believer that a reference to RFC 5245 is also appropriate in transports. This draft was changed in version -17 to refer to 5245bis. From GH: "The drafts -bundle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a normative dependency from -transport on these. So consistency of the bundle is improved by referencing 5245bis.". >> >> [BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtcweb-transports which has a normative reference to draft-ietf-ice-dualstack-fairness which in turn has a normative reference to draft-ietf-ice-rfc5245bis. So even if you remove the normative reference to RFC5245bis from overview and transports, publication of overview will still be held up until publication of RFC 5245bis, which will obsolete RFC 5245. >> >> >> >> On Thu, May 18, 2017 at 8:37 AM, Sean Turner wrote: >> >> >>> On May 18, 2017, at 11:35, Sean Turner wrote: >>> >>> >>>> On May 18, 2017, at 10:54, Martin Thomson wrote: >>>> >>>> I'm really confused about the statement regarding -transports. You >>>> say that 5245 is sufficient, then follow with justification for the >>>> opposite position. >>> Sorry the change from 5425 to 5245bis was included in the latest version using that rationale. This shows to me that it was “nice” to get alignment and point to 5245bis not that it is necessary to point 5245. I.e., it’d be just fine to switch it back to referring to 5245. >> Whoops: >> >> This shows to me that it was “nice” to get alignment and point to 5245bis not that it is necessary to point 5245bis. I.e., it’d be just fine to switch it back to referring to 5245. >> >> >>>> If we have as large a dependency as bundle that refers to 5245bis, >>>> then we are taking a transitive dependency on 5245bis and might as >>>> well refer to that. >>>> >>>> A lot of this comes down to what bundle says. Now, I see that bundle >>>> depends on both 5245 and its -bis, which seems pretty inconsistent. I >>>> don't immediately see any strong reason for bundle to refer to the >>>> -bis, though it does refer to the ice-sip-sdp draft, which might be >>>> sufficiently implicated as to make the change necessary. We should >>>> ask Christer to confirm this. >>>> >>>> I think that if we clarify that either way, then the reference in >>>> -dualstack-fairness seems less of a concern; that document doesn't >>>> need to reference 5245bis, though it would be nice if it could. >>> Exactly! >>> >>> spt >>> >>>> On 18 May 2017 at 10:12, Sean Turner wrote: >>>>> ekr’s discuss on draft-ietf-rtcweb-overview has raised whether drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. We only need to normatively refer to 5245bis if a technical part of 5245bis needs to be read and implemented in order to implement the referring draft. We have 7 drafts that refer to RFC 5245 and 2 that refer to draft-ietf-rfc5245bis: >>>>> >>>>> draft-ietf-rtcweb-overview: As noted in my response to ekr’s discuss position [0], the chairs believe that the reference to “ICE” in the ICE Agent definition should be to RFC 5245. >>>>> >>>>> draft-ietf-rtcweb-transports: Likewise, the chairs believer that a reference to RFC 5245 is also appropriate in transports. This draft was changed in version -17 to refer to 5245bis. From GH: "The drafts -bundle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a normative dependency from -transport on these. So consistency of the bundle is improved by referencing 5245bis." >>>>> >>>>> spt >>>>> >>>>> [0] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8 >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jun 2 08:18:44 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCE8129BEC for ; Fri, 2 Jun 2017 08:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iHB9xycfuVY for ; Fri, 2 Jun 2017 08:18:40 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA516128854 for ; Fri, 2 Jun 2017 08:18:40 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m47so4599806iti.1 for ; Fri, 02 Jun 2017 08:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mb4BZMr1aA/O0f++MyYu8foT/NXHKk8qTFilWBBJ8k8=; b=hXiK9Xnnh7RVBZqQa6B7Lau+4T6LfPsRWhLUpkLkEhdQ6xwKZ6xcZoDX37FfmKMXX1 HEppxKGzAV0onpCPIEzqNe7U1e3MCTIQZEs8J58E0arXrbovGVYOY7gauGEoMzvhtKDC FPsy84Cmy3QQjfoAS97tllInJ31WhpmIYfRA0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mb4BZMr1aA/O0f++MyYu8foT/NXHKk8qTFilWBBJ8k8=; b=VNf+bL/XuBCkTLrSh3/bv8JTzZJXShYWbzEa1oxwuasLPzRRt6J1jlLApaQOmCVhm3 cKfdO5a7fKarWXp3cO14XvFza34n1O7C6haLcRL5TdY8BBSvvVdrX8Avzsmz3OokD6Za Ea6Mma6eIFbm17MGwXV8yd3iknTlHqSeEGKA6hlDYvm/KZm1Fih0POJ+O4nAWYREcVwV 2+NiiQFEesfWdgUcJMkYNAlsdODjkJsnUXtfastpHoXFUCXQZGpEATOERq8dE8c8RhG3 ZVMRPUWG0jXImJZTyCBd/y5UyNdAyLiB0pa0t62LxK6PhasaWdOS59YAU/mrd9KhFwUK L6Xg== X-Gm-Message-State: AODbwcAdd3Yi5Adk1smbJ+wtydvvj7BxlFrjWB/v0yfI1pvAhD9nFFcF 5fNfLxMklC6KGf7s X-Received: by 10.36.137.213 with SMTP id s204mr5245076itd.64.1496416720019; Fri, 02 Jun 2017 08:18:40 -0700 (PDT) Received: from [5.5.33.145] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id b69sm1176335itb.23.2017.06.02.08.18.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 08:18:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> Date: Fri, 2 Jun 2017 11:18:37 -0400 Cc: The IESG , draft-ietf-rtcweb-overview@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149285978295.25905.7347383325486705546.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 15:18:43 -0000 > On Apr 22, 2017, at 07:16, Eric Rescorla wrote: >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This document seems rather long on philosophy (justifying MTI, > the freed to innovate material in S 4.) I would remove all this. I can get on board with the less is more philosophy but here I think = it=E2=80=99s just Harald building up the narrative. Because it=E2=80=99s = not really doing harm and I=E2=80=99m afraid of going too far in the = other direction and playing bring me rock, I=E2=80=99m inclined to just = leave it. > S 2.4. > Why do you have two terminology sections? I would merge them. Yes - we should merge them. Here=E2=80=99s a PR: https://github.com/rtcweb-wg/rtcweb-overview/pull/43/files > S 3. > The diagrams here seem to assume a federation model that I > generally don't see used with WebRTC. So, for instance, > the on-the-wire protocols arrow on page 9. Who does that? > This also applies to "a commonly imagined model" >=20 > I would say HTTP(S) in this diagram. https://github.com/rtcweb-wg/rtcweb-overview/pull/39/files > You should probably list DTLS, SCTP, and SDP in this section. It's > not like we haven't decided we need them. Note SCTP is already listed in data framing, but here=E2=80=99s a PR: https://github.com/rtcweb-wg/rtcweb-overview/pull/37 > "The functionality groups that are needed in the browser can be > specified, more or less from the bottom up, as: > ... > Connection management: ... SIP and Jingle/XMPP belong in this > category." >=20 > As far as I know, nothing in this layer is specified in WebRTC > or implemented in the browser, so this doesn't seem to make > sense. Not sure what to do about these so suggestions from the WG are welcome. spt= From nobody Fri Jun 2 18:51:21 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8EF129B73 for ; Fri, 2 Jun 2017 18:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_0yb1R14TwO for ; Fri, 2 Jun 2017 18:51:17 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2311243F6 for ; Fri, 2 Jun 2017 18:51:17 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id r63so35175809itc.1 for ; Fri, 02 Jun 2017 18:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=/BzZEZ6SMQo12VGT2L8bYAfANAZUlWBXrIoT5tdl4p8=; b=CYqFIBGZSFrqHvHEVNXDtkmq5WhIHzOveul+pHzHvCUA2mLENhKn4kIAGPxHv1+nkk QcSjj4mhtwJM56vy3ri6+ABGvOl1RgC90/uPaZpbSS5bqV8k5GEK0w0QzKvz2QBq84Os D5jQI7cB0VbDaLN20NSo7bjrwYvCiGVJW5pdM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=/BzZEZ6SMQo12VGT2L8bYAfANAZUlWBXrIoT5tdl4p8=; b=DraTYhfNiAb3JtdbxyzQby0Lc2i4NVGUQ1h2euLEn5aCdwmdeqxqWVLk3zUh0VvHhu KmZ+YMJkZOLwyg9IVo4ibbr6Mza6Lny8A2SkuXXG4oELDRC4JvU+KrqLKulM3iQsWiaT RxJ/Z32XzzF3r6qGkjoworQfew2PPyR5ORMlRANVFntNM7kj3P22LHu4NP9jVxw0Nttd FlA+yn6IX8jTq4V1aP+kTTYMqHk58VsW2QzsshJD/PAoXrq4+q4IOh5+yG89w6iC4to5 rBBzC+DO6IbmabhIO2SHAlDxY5y3rDD9602f+fWRY4LXKTyBkItXGC3AYa+QOXsgQd6I /eyA== X-Gm-Message-State: AODbwcDN/fxqceIdavBa8FoKVMAPkjlfV3GoPuM44YbYejX5UsdGIwXI skAMYxMz0zykYlsKwkx6fA== X-Received: by 10.36.121.141 with SMTP id z135mr2328154itc.36.1496454676800; Fri, 02 Jun 2017 18:51:16 -0700 (PDT) Received: from [5.5.33.157] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id n3sm2106812itg.3.2017.06.02.18.51.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 18:51:16 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <9640A231-0FB2-4BAC-9406-3C0E2AEBB709@sn3rd.com> Date: Fri, 2 Jun 2017 21:51:09 -0400 To: RTCWeb IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-overview status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 01:51:19 -0000 All, I=E2=80=99ve submitted a number of PRs to address the IESG review = comments. They can be found here: https://github.com/rtcweb-wg/rtcweb-overview/pulls All of the ADs have said they were fine with the changes, except ekr but = I believe he will clear his discuss once he gets a chance to review the = PR that addresses his discuss. Please let the list know if you have any = issues with the proposed changes as proposed by COB June 9th (in = whatever timezone you=E2=80=99re in) because after that time the chairs = are going to ping Harald while he=E2=80=99s on his walkabout to merge = the PRs and submit a new version that our illustrious AD can move into = the IESG approved state. spt= From nobody Sat Jun 3 22:48:54 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA3C1294B9 for ; Sat, 3 Jun 2017 22:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U28kUvZIaxls for ; Sat, 3 Jun 2017 22:48:51 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259DF1270A3 for ; Sat, 3 Jun 2017 22:48:51 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m62so37715444itc.0 for ; Sat, 03 Jun 2017 22:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=kUlcZoUtWJkXsGWMbHvRrSb8GLN54XUMj/XFD6FJ1L4=; b=TsCbT+bBX5ev6QmImYdY8HmAvfXZn0p70EG4PFPWi+l08K4ilGkgmPRxS3yAHSAwAc lb0dWvzkm9Jq5JDHqdXhJ748R7kS7YxlztOT296QT/Mm8OwlCB8fjxx3C7dJTeQXqsMO kdmaV3Figx4QlyHbjvcQ9sEC15n4L7MLLuQMs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=kUlcZoUtWJkXsGWMbHvRrSb8GLN54XUMj/XFD6FJ1L4=; b=T6ZWTmY4W1DSO40Qr3a1lxO+wU9TsGbcuM/ppJtEB6qMTz6HWNCA8Fl7HRvg/nqzcV IrH/5PEKgX2dHX2Fi0ol2KuuXAo1Oo3nGFe/0DN/Mr9orhwANc5xkWgdUpZHwnLC+INH RYV5eEySkjGhwYGMyQeTBpwHJsxVVEYNATXXRTfsHLtIDt/6OPU1J115mQJ+L54Jg57n s/WtkJR8nq/aL02VVIoLNdHoXHI1Bfi0xcB5oMrm1gYg7GhqrUPyoDLKoBvTjtTJ7rme Hdn9M9291hZHBDYa8v7NSLmZFMMfLhKJZMwvFMWaDfPhGRIBTa2kbR3dMWUzGH3DDq7I +fgQ== X-Gm-Message-State: AODbwcAFXUHF8/Te4vR7zNPNNpdqrv7+wiz5iGGtt4iyIpF0axWZnQgK iydNZcUitHWXHU0k31n2YA== X-Received: by 10.107.47.66 with SMTP id j63mr13951670ioo.203.1496555330236; Sat, 03 Jun 2017 22:48:50 -0700 (PDT) Received: from [5.5.33.201] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id u100sm12376666iou.52.2017.06.03.22.48.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 22:48:49 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <468C4F72-689A-4BE3-84F8-443C769A040E@sn3rd.com> Date: Sun, 4 Jun 2017 01:48:47 -0400 To: RTCWeb IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [rtcweb] PRs for IP-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 05:48:52 -0000 All, Thanks go to Martin and Bernard for their reviews of = draft-ietf-rtcweb-ip-handling. I have converted their comments into = issue in Justin=E2=80=99s GH repo for this (and other) drafts for your = review: https://github.com/juberti/draughts/issues/created_by/seanturner spt= From nobody Sun Jun 4 06:47:28 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB9B12946C for ; Sun, 4 Jun 2017 06:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 iHbVcYRrLHyQ for ; Sun, 4 Jun 2017 06:47:25 -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 C1927129469 for ; Sun, 4 Jun 2017 06:47:24 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-28-59340f6a9159 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2A.B1.03383.A6F04395; Sun, 4 Jun 2017 15:47:22 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Sun, 4 Jun 2017 15:45:09 +0200 From: Christer Holmberg To: Sean Turner , RTCWeb IETF Thread-Topic: [rtcweb] draft-ietf-rtcweb-overview status Thread-Index: AQHS3Avr0Bn0GDa0D0C76imZVG+DaaIUuTdA Date: Sun, 4 Jun 2017 13:45:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBD9487@ESESSMB109.ericsson.se> References: <9640A231-0FB2-4BAC-9406-3C0E2AEBB709@sn3rd.com> In-Reply-To: <9640A231-0FB2-4BAC-9406-3C0E2AEBB709@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM2K7hG4Wv0mkwaINhhZr/7WzW1xZ1cjs wOSxZMlPJo+DBxkDmKK4bFJSczLLUov07RK4Mla9XMde8IOn4v/+E0wNjGd4uhg5OSQETCTe vXvH2sXIxSEkcIRR4njPUWYIZxGjRP+tJ0AOBwebgIVE9z9tkAYRAXuJm7tbWEHCwgLmEncm ekCELSR+7Z7OCmEbSXzr28sEUsIioCLxdjdYmFfAV+LqggvMILaQgI3EqqWvwIZzCthKzJlT ChJmFBCT+H5qDROIzSwgLnHryXwmiCsFJJbsOc8MYYtKvHz8jxXCVpJYdPsz2CZmAU2J9bv0 IVoVJaZ0P2SH2CoocXLmE5YJjCKzkEydhdAxC0nHLCQdCxhZVjGKFqcWF+emGxnrpRZlJhcX 5+fp5aWWbGIExsDBLb91dzCufu14iFGAg1GJhzeP0yRSiDWxrLgy9xCjBAezkgjv14fGkUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUw2nOe97/bzOe9 okOn6oBN5Ae/+SJT+xe5rufi+HqtOiR1e+ffBzesE+sSK89UcF+ZG7/UgyFi0xnNK6XTSjOc ym9LNt2/+ab+1VFVL9VVVqn7dHcHJGYv5K4S0p/3vXH29fNf5jd+mxz6ZdeHimOTv0i+Nnl7 aM4mNZE151fWPvj7c5fzyQ/zJJRYijMSDbWYi4oTAWJ8vC59AgAA Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-overview status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:47:26 -0000 SGksDQoNCkkgdGhpbmsgd2Ugc3RpbGwgbmVlZCB0byBoYXZlIGEgZGlzY3Vzc2lvbiByZWdhcmRp bmcgdGhlIElDRSByZWZlcmVuY2UuDQoNCkknZCBhdCBsZWFzdCBsaWtlIHRvIGhhdmUgYSAiZ28g YWhlYWQiIGJ5IHRoZSBJQ0UgYW5kIE1NVVNJQyBjaGFpcnMvYXV0aG9ycy4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYiBb bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2VhbiBUdXJuZXIN ClNlbnQ6IDAzIEp1bmUgMjAxNyAwMzo1MQ0KVG86IFJUQ1dlYiBJRVRGIDxydGN3ZWJAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbcnRjd2ViXSBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldyBzdGF0dXMN Cg0KQWxsLA0KDQpJ4oCZdmUgc3VibWl0dGVkIGEgbnVtYmVyIG9mIFBScyB0byBhZGRyZXNzIHRo ZSBJRVNHIHJldmlldyBjb21tZW50cy4gIFRoZXkgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczov L2dpdGh1Yi5jb20vcnRjd2ViLXdnL3J0Y3dlYi1vdmVydmlldy9wdWxscw0KQWxsIG9mIHRoZSBB RHMgaGF2ZSBzYWlkIHRoZXkgd2VyZSBmaW5lIHdpdGggdGhlIGNoYW5nZXMsIGV4Y2VwdCBla3Ig YnV0IEkgYmVsaWV2ZSBoZSB3aWxsIGNsZWFyIGhpcyBkaXNjdXNzIG9uY2UgaGUgZ2V0cyBhIGNo YW5jZSB0byByZXZpZXcgdGhlIFBSIHRoYXQgYWRkcmVzc2VzIGhpcyBkaXNjdXNzLiAgUGxlYXNl IGxldCB0aGUgbGlzdCBrbm93IGlmIHlvdSBoYXZlIGFueSBpc3N1ZXMgd2l0aCB0aGUgcHJvcG9z ZWQgY2hhbmdlcyBhcyBwcm9wb3NlZCBieSBDT0IgSnVuZSA5dGggKGluIHdoYXRldmVyIHRpbWV6 b25lIHlvdeKAmXJlIGluKSBiZWNhdXNlIGFmdGVyIHRoYXQgdGltZSB0aGUgY2hhaXJzIGFyZSBn b2luZyB0byBwaW5nIEhhcmFsZCB3aGlsZSBoZeKAmXMgb24gaGlzIHdhbGthYm91dCB0byBtZXJn ZSB0aGUgUFJzIGFuZCBzdWJtaXQgYSBuZXcgdmVyc2lvbiB0aGF0IG91ciBpbGx1c3RyaW91cyBB RCBjYW4gbW92ZSBpbnRvIHRoZSBJRVNHIGFwcHJvdmVkIHN0YXRlLg0KDQpzcHQNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBs aXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViDQo= From nobody Mon Jun 5 05:44:41 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4292129521 for ; Mon, 5 Jun 2017 05:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLWjJunYWMhu for ; Mon, 5 Jun 2017 05:44:38 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6D1128959 for ; Mon, 5 Jun 2017 05:44:38 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l74so52962707ywe.2 for ; Mon, 05 Jun 2017 05:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BToVkU8aaaI0vHxTZwLUQKm8bvG9JBbjo0EEDrHmdFI=; b=mci03AJFt06jaWn2eeLqP7TKAlDrpMyzkSsdtgf8Qn9RiGRKekWD5dJScaG4KPPYuu k8ymJT4irRH3fpTJFsLZSU5936AYNLjJpmZtnF+i42hoPulSK8lofyqb5Kt/Wwn7CG7u auFjFJo7KyLH5OmDrjlIscB0eqehRRY7mkdWfyeE97Kww4OMSJol+UV6Fl0dkXd9OFYU LPpKbU+R+uV0DbbZsNeIobjoLCt27+sNN2cU8n/5jgOl0lujEcUdqHJKxsqQTnY2sRbG ltj/ZDcasr5lcTJnOjolTKy0x7iafs00rBq8CxboPB9qjPacTdkap3wfGQTiDJXd6vVu eOag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BToVkU8aaaI0vHxTZwLUQKm8bvG9JBbjo0EEDrHmdFI=; b=a1zOgv16A8OtfdVH95MQJzck3H9CJytQ3/C5vSuOPgi90RCic6MIDIgnGK9LIVVUnA KztUT4d8AVAy48x2i5oWjDXujH0janhGfnEgYvsQKdL+1HWaDBK56H8tRexE5Asyer+u pV7eoGhu57mkjvId7HZWSaq0hXgCY0ALI+bnOURgHr4UcSSQRYOJAY6hc8UEOaeP6P94 nrancqn4qBUFahJva0zjwGSnmCLe4YNL2r7X/vIHWKcrUwMSRPXIwUj1CRNEWgAdNm1n DtMt4fi/5egXeiowguoUAAPbxel4UMNkePYU1a0VtoJXIRYO2rTefOHrPPMvdz4+5if8 4x2g== X-Gm-Message-State: AODbwcDs9LPVKgV5Qoa7GsNLQaY/E4JKO9b5JYRX/9ZBvW0Dd8RXLs/I dnzwj2xeJF8IZEtXTtYoP+3COv9gYEol X-Received: by 10.129.57.138 with SMTP id g132mr14411497ywa.312.1496666677728; Mon, 05 Jun 2017 05:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.4 with HTTP; Mon, 5 Jun 2017 05:43:57 -0700 (PDT) In-Reply-To: <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> From: Eric Rescorla Date: Mon, 5 Jun 2017 14:43:57 +0200 Message-ID: To: Flemming Andreasen Cc: Cullen Jennings , Christer Holmberg , "mmusic-chairs@tools.ietf.org" , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a114c76b4ac8432055135dd70" Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 12:44:41 -0000 --001a114c76b4ac8432055135dd70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Do you have the names of those drafts to hand? On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen wrote: > Please note that we have several drafts in MMUSIC that normatively > reference 5245bis, and some of those drafts are RTCWeb dependencies AFAIK= . > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > On 5/22/17 6:52 PM, Cullen Jennings wrote: > >> Note that I don't think the timeline is the major issue (it is an issue) >> ... they key issue is that 5245bis does not seem to be needed for any >> technical reason by WebRTC. >> >> >> On May 18, 2017, at 11:03 AM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>> Hi, >>> >>> >>> In general, if people have issues with referencing 5245bis because they >>> are afraid it will hold up publication of RTCWEB specs, note that I hav= e >>> indicated to the ICE WG chairs that I think 5245bis is getting ready fo= r >>> WGLC. >>> >>> >>> Regards, >>> >>> >>> Christer >>> >>> >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Abob= a >>> Sent: 18 May 2017 18:50 >>> To: Sean Turner >>> Cc: RTCWeb IETF >>> Subject: Re: [rtcweb] Referring to 5245bis or 5245? >>> >>> >>> Sean said: >>> >>> >>> "draft-ietf-rtcweb-transports: Likewise, the chairs believer that a >>> reference to RFC 5245 is also appropriate in transports. This draft wa= s >>> changed in version -17 to refer to 5245bis. From GH: "The drafts -bund= le >>> and -dualstack-fairness both depend on 5245bis according to Cullen's ch= art >>> in 'rtcweb-deps-13', and we already have a normative dependency from >>> -transport on these. So consistency of the bundle is improved by >>> referencing 5245bis.". >>> >>> [BA] draft-ietf-rtcweb-overview has a normative reference to >>> draft-ietf-rtcweb-transports which has a normative reference to >>> draft-ietf-ice-dualstack-fairness which in turn has a normative >>> reference to draft-ietf-ice-rfc5245bis. So even if you remove the >>> normative reference to RFC5245bis from overview and transports, publica= tion >>> of overview will still be held up until publication of RFC 5245bis, whi= ch >>> will obsolete RFC 5245. >>> >>> >>> On Thu, May 18, 2017 at 8:37 AM, Sean Turner wrote: >>> >>> >>> On May 18, 2017, at 11:35, Sean Turner wrote: >>>> >>>> >>>> On May 18, 2017, at 10:54, Martin Thomson >>>>> wrote: >>>>> >>>>> I'm really confused about the statement regarding -transports. You >>>>> say that 5245 is sufficient, then follow with justification for the >>>>> opposite position. >>>>> >>>> Sorry the change from 5425 to 5245bis was included in the latest >>>> version using that rationale. This shows to me that it was =E2=80=9Cn= ice=E2=80=9D to get >>>> alignment and point to 5245bis not that it is necessary to point 5245. >>>> I.e., it=E2=80=99d be just fine to switch it back to referring to 5245= . >>>> >>> Whoops: >>> >>> This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment an= d point to >>> 5245bis not that it is necessary to point 5245bis. I.e., it=E2=80=99d = be just fine >>> to switch it back to referring to 5245. >>> >>> >>> If we have as large a dependency as bundle that refers to 5245bis, >>>>> then we are taking a transitive dependency on 5245bis and might as >>>>> well refer to that. >>>>> >>>>> A lot of this comes down to what bundle says. Now, I see that bundle >>>>> depends on both 5245 and its -bis, which seems pretty inconsistent. = I >>>>> don't immediately see any strong reason for bundle to refer to the >>>>> -bis, though it does refer to the ice-sip-sdp draft, which might be >>>>> sufficiently implicated as to make the change necessary. We should >>>>> ask Christer to confirm this. >>>>> >>>>> I think that if we clarify that either way, then the reference in >>>>> -dualstack-fairness seems less of a concern; that document doesn't >>>>> need to reference 5245bis, though it would be nice if it could. >>>>> >>>> Exactly! >>>> >>>> spt >>>> >>>> On 18 May 2017 at 10:12, Sean Turner wrote: >>>>> >>>>>> ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised wheth= er drafts >>>>>> should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. We only need= to >>>>>> normatively refer to 5245bis if a technical part of 5245bis needs to= be >>>>>> read and implemented in order to implement the referring draft. We = have 7 >>>>>> drafts that refer to RFC 5245 and 2 that refer to draft-ietf-rfc524= 5bis: >>>>>> >>>>>> draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s= discuss >>>>>> position [0], the chairs believe that the reference to =E2=80=9CICE= =E2=80=9D in the ICE >>>>>> Agent definition should be to RFC 5245. >>>>>> >>>>>> draft-ietf-rtcweb-transports: Likewise, the chairs believer that a >>>>>> reference to RFC 5245 is also appropriate in transports. This draft= was >>>>>> changed in version -17 to refer to 5245bis. From GH: "The drafts -b= undle >>>>>> and -dualstack-fairness both depend on 5245bis according to Cullen's= chart >>>>>> in 'rtcweb-deps-13', and we already have a normative dependency from >>>>>> -transport on these. So consistency of the bundle is improved by >>>>>> referencing 5245bis." >>>>>> >>>>>> spt >>>>>> >>>>>> [0] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtz >>>>>> zqugnELKeaY8 >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>> >>>>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114c76b4ac8432055135dd70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you have the names of those drafts to hand?

On Fri, Jun 2, 2017 at = 3:40 PM, Flemming Andreasen <fandreas@cisco.com> wrote:
=
Please note that we have several drafts in M= MUSIC that normatively reference 5245bis, and some of those drafts are RTCW= eb dependencies AFAIK.

Thanks

-- Flemming (as MMUSIC co-chair)

On 5/22/17 6:52 PM, Cullen Jennings wrote:
Note that I don't think the timeline is the major issue (it is an issue= ) ... they key issue is that 5245bis does not seem to be needed for any tec= hnical reason by WebRTC.


On May 18, 2017, at 11:03 AM, Christer Holmberg <christer.holmberg@ericsson.co<= wbr>m> wrote:

Hi,

=C2=A0
In general, if people have issues with referencing 5245bis because they are= afraid it will hold up publication of RTCWEB specs, note that I have indic= ated to the ICE WG chairs that I think 5245bis is getting ready for WGLC.
=C2=A0
Regards,

=C2=A0
Christer

=C2=A0
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 18 May 2017 18:50
To: Sean Turner <sea= n@sn3rd.com>
Cc: RTCWeb IETF <rt= cweb@ietf.org>
Subject: Re: [rtcweb] Referring to 5245bis or 5245?

=C2=A0
Sean said:

=C2=A0
"draft-ietf-rtcweb-transports: Likewise, the chairs believer that a re= ference to RFC 5245 is also appropriate in transports.=C2=A0 This draft was= changed in version -17 to refer to 5245bis.=C2=A0 From GH: "The draft= s -bundle and -dualstack-fairness both depend on 5245bis according to Culle= n's chart in 'rtcweb-deps-13', and we already have a normative = dependency from -transport on these.=C2=A0 So consistency of the bundle is = improved by referencing 5245bis.".

[BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtc= web-transports which has a normative reference to draft-ietf-ice-dualstack-= fairness which in turn has a normative reference to draft-ietf-ice-rfc= 5245bis.=C2=A0 So even if you remove the normative reference to RFC5245bis = from overview and transports, publication of overview will still be held up= until publication of RFC 5245bis, which will obsolete RFC 5245.

=C2=A0
On Thu, May 18, 2017 at 8:37 AM, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 11:35, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 10:54, Martin Thomson <martin.thomson@gmail.com> wrote:
I'm really confused about the statement regarding -transports.=C2=A0 Yo= u
say that 5245 is sufficient, then follow with justification for the
opposite position.
Sorry the change from 5425 to 5245bis was included in the latest version us= ing that rationale.=C2=A0 This shows to me that it was =E2=80=9Cnice=E2=80= =9D to get alignment and point to 5245bis not that it is necessary to point= 5245.=C2=A0 I.e., it=E2=80=99d be just fine to switch it back to referring= to 5245.
Whoops:

This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment and po= int to 5245bis not that it is necessary to point 5245bis.=C2=A0 I.e., it=E2= =80=99d be just fine to switch it back to referring to 5245.


If we have as large a dependency as bundle that refers to 5245bis,
then we are taking a transitive dependency on 5245bis and might as
well refer to that.

A lot of this comes down to what bundle says.=C2=A0 Now, I see that bundle<= br> depends on both 5245 and its -bis, which seems pretty inconsistent.=C2=A0 I=
don't immediately see any strong reason for bundle to refer to the
-bis, though it does refer to the ice-sip-sdp draft, which might be
sufficiently implicated as to make the change necessary.=C2=A0 We should ask Christer to confirm this.

I think that if we clarify that either way, then the reference in
-dualstack-fairness seems less of a concern; that document doesn't
need to reference 5245bis, though it would be nice if it could.
Exactly!

spt

On 18 May 2017 at 10:12, Sean Turner <sean@sn3rd.com> wrote:
ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised whether draf= ts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis.=C2=A0 We only nee= d to normatively refer to 5245bis if a technical part of 5245bis needs to b= e read and implemented in order to implement the referring draft.=C2=A0 We = have 7 drafts that refer to RFC 5245 and 2=C2=A0 that refer to draft-ietf-r= fc5245bis:

draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s discus= s position [0], the chairs believe that the reference to =E2=80=9CICE=E2=80= =9D in the ICE Agent definition should be to RFC 5245.

draft-ietf-rtcweb-transports: Likewise, the chairs believer that a referenc= e to RFC 5245 is also appropriate in transports.=C2=A0 This draft was chang= ed in version -17 to refer to 5245bis.=C2=A0 From GH: "The drafts -bun= dle and -dualstack-fairness both depend on 5245bis according to Cullen'= s chart in 'rtcweb-deps-13', and we already have a normative depend= ency from -transport on these.=C2=A0 So consistency of the bundle is improv= ed by referencing 5245bis."

spt

[0] https://mailarchive.ietf= .org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

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

--001a114c76b4ac8432055135dd70-- From nobody Wed Jun 7 07:50:13 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A60612EC8F for ; Wed, 7 Jun 2017 07:50:11 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4mVMYgRVvI9D for ; Wed, 7 Jun 2017 07:50:08 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02B9129488 for ; Wed, 7 Jun 2017 07:50:07 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id h4so6547516oib.3 for ; Wed, 07 Jun 2017 07:50:07 -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=jnqEdpL/M8HCgmigWz+K9sXOO8jOQYrDaKTkYNgOuZY=; b=v2Ji54TPwWibCh2W5ZiSeH1Xa9DGLNbC5KJ7s7GNocuVspdabb0YXaYWZh0eAQjSzx 9v3kUp3/jqgYTjhsxC5RzzllWYsAFKVS8K6kSgu0CTw3HdSPQc80ChiXrz4ZFMC+7DtH 2BMT6NM1GRQV5ulK86IRt/GAHCVCOq4dyakM+r5KVn+8BZ4SplTY9pnF7nP08o0oqLBK 3vkRz+Gf2D44DZCIW3C6kQd+JuHt40nQ4+q8a0BT8RfO7WgfZEl+qlMAmlsWrkHurALr ukaqBAFJsFKrb9Tl0pGVZ8Ua09ABGStTH3pIj+pgSmb937DpxW4ah+/D0xpu56T/rzk9 5omw== 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=jnqEdpL/M8HCgmigWz+K9sXOO8jOQYrDaKTkYNgOuZY=; b=by6QfX5EYshozxmOg+XKWOg5y1s2NDU+fMm9V5FvfHmhV5cWUdo+B19Ekq60M+BHPD qSJd3WJbxi12fIGjso9vn623VAIoYjCKok0bhg0TviCtShL1RdAvUNGCnMO5562D5cHG GxjUrBJi+ueur0EbdiviMIY3quQPCA53pZa9nt2QEk4qG3G2uzZo9SrTAR7SF8Yg2vRn rzySb6a0CdKF1+EviusOI9cK4U3m0zCz2bbvnqBRoc89R9jLBFehu19Osoue98dVlYgE K8HThiBB/vDgPAIl+27hrb8ksNA9WTJS/LYt6ISZ73rS/xT3mTu8S8oWs+t/9+rCYbCj xzRg== X-Gm-Message-State: AODbwcBPvxnDteiPbv4RBlpKFvsQAT1QzWi9pTXGEE4YChX7IWtXIOS1 SOxr/PqsMKgegkS88TrkvrrJ1SxP9Qqe X-Received: by 10.202.77.205 with SMTP id a196mr9722089oib.90.1496847007089; Wed, 07 Jun 2017 07:50:07 -0700 (PDT) MIME-Version: 1.0 References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> In-Reply-To: From: Peter Thatcher Date: Wed, 07 Jun 2017 14:49:55 +0000 Message-ID: To: Eric Rescorla , Flemming Andreasen Cc: "mmusic-chairs@tools.ietf.org" , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a11352e4a2482ec05515fda99" Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 14:50:11 -0000 --001a11352e4a2482ec05515fda99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's not an MMUSIC dependency, but JSEP relies on trickle-ice and trickle-ice relies on 5245bis, and there are definite technical reasons for both of those dependencies. So I don't see how JSEP can avoid depending on 5245bis, at least indirectly. On Mon, Jun 5, 2017 at 5:44 AM Eric Rescorla wrote: > Do you have the names of those drafts to hand? > > On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen > wrote: > >> Please note that we have several drafts in MMUSIC that normatively >> reference 5245bis, and some of those drafts are RTCWeb dependencies AFAI= K. >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> >> On 5/22/17 6:52 PM, Cullen Jennings wrote: >> >>> Note that I don't think the timeline is the major issue (it is an issue= ) >>> ... they key issue is that 5245bis does not seem to be needed for any >>> technical reason by WebRTC. >>> >>> >>> On May 18, 2017, at 11:03 AM, Christer Holmberg < >>>> christer.holmberg@ericsson.com> wrote: >>>> >>>> Hi, >>>> >>>> >>>> In general, if people have issues with referencing 5245bis because the= y >>>> are afraid it will hold up publication of RTCWEB specs, note that I ha= ve >>>> indicated to the ICE WG chairs that I think 5245bis is getting ready f= or >>>> WGLC. >>>> >>>> >>>> Regards, >>>> >>>> >>>> Christer >>>> >>>> >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard >>>> Aboba >>>> Sent: 18 May 2017 18:50 >>>> To: Sean Turner >>>> Cc: RTCWeb IETF >>>> Subject: Re: [rtcweb] Referring to 5245bis or 5245? >>>> >>>> >>>> Sean said: >>>> >>>> >>>> "draft-ietf-rtcweb-transports: Likewise, the chairs believer that a >>>> reference to RFC 5245 is also appropriate in transports. This draft w= as >>>> changed in version -17 to refer to 5245bis. From GH: "The drafts -bun= dle >>>> and -dualstack-fairness both depend on 5245bis according to Cullen's c= hart >>>> in 'rtcweb-deps-13', and we already have a normative dependency from >>>> -transport on these. So consistency of the bundle is improved by >>>> referencing 5245bis.". >>>> >>>> [BA] draft-ietf-rtcweb-overview has a normative reference to >>>> draft-ietf-rtcweb-transports which has a normative reference to >>>> draft-ietf-ice-dualstack-fairness which in turn has a normative refere= nce >>>> to draft-ietf-ice-rfc5245bis. So even if you remove the normative >>>> reference to RFC5245bis from overview and transports, publication of >>>> overview will still be held up until publication of RFC 5245bis, which= will >>>> obsolete RFC 5245. >>>> >>>> >>>> On Thu, May 18, 2017 at 8:37 AM, Sean Turner wrote: >>>> >>>> >>>> On May 18, 2017, at 11:35, Sean Turner wrote: >>>>> >>>>> >>>>> On May 18, 2017, at 10:54, Martin Thomson >>>>>> wrote: >>>>>> >>>>>> I'm really confused about the statement regarding -transports. You >>>>>> say that 5245 is sufficient, then follow with justification for the >>>>>> opposite position. >>>>>> >>>>> Sorry the change from 5425 to 5245bis was included in the latest >>>>> version using that rationale. This shows to me that it was =E2=80=9C= nice=E2=80=9D to get >>>>> alignment and point to 5245bis not that it is necessary to point 5245= . >>>>> I.e., it=E2=80=99d be just fine to switch it back to referring to 524= 5. >>>>> >>>> Whoops: >>>> >>>> This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment a= nd point to >>>> 5245bis not that it is necessary to point 5245bis. I.e., it=E2=80=99d= be just fine >>>> to switch it back to referring to 5245. >>>> >>>> >>>> If we have as large a dependency as bundle that refers to 5245bis, >>>>>> then we are taking a transitive dependency on 5245bis and might as >>>>>> well refer to that. >>>>>> >>>>>> A lot of this comes down to what bundle says. Now, I see that bundl= e >>>>>> depends on both 5245 and its -bis, which seems pretty inconsistent. = I >>>>>> don't immediately see any strong reason for bundle to refer to the >>>>>> -bis, though it does refer to the ice-sip-sdp draft, which might be >>>>>> sufficiently implicated as to make the change necessary. We should >>>>>> ask Christer to confirm this. >>>>>> >>>>>> I think that if we clarify that either way, then the reference in >>>>>> -dualstack-fairness seems less of a concern; that document doesn't >>>>>> need to reference 5245bis, though it would be nice if it could. >>>>>> >>>>> Exactly! >>>>> >>>>> spt >>>>> >>>>> On 18 May 2017 at 10:12, Sean Turner wrote: >>>>>> >>>>>>> ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised whet= her >>>>>>> drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. We o= nly need >>>>>>> to normatively refer to 5245bis if a technical part of 5245bis need= s to be >>>>>>> read and implemented in order to implement the referring draft. We= have 7 >>>>>>> drafts that refer to RFC 5245 and 2 that refer to draft-ietf-rfc52= 45bis: >>>>>>> >>>>>>> draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99= s discuss >>>>>>> position [0], the chairs believe that the reference to =E2=80=9CICE= =E2=80=9D in the ICE >>>>>>> Agent definition should be to RFC 5245. >>>>>>> >>>>>>> draft-ietf-rtcweb-transports: Likewise, the chairs believer that a >>>>>>> reference to RFC 5245 is also appropriate in transports. This draf= t was >>>>>>> changed in version -17 to refer to 5245bis. From GH: "The drafts -= bundle >>>>>>> and -dualstack-fairness both depend on 5245bis according to Cullen'= s chart >>>>>>> in 'rtcweb-deps-13', and we already have a normative dependency fro= m >>>>>>> -transport on these. So consistency of the bundle is improved by >>>>>>> referencing 5245bis." >>>>>>> >>>>>>> spt >>>>>>> >>>>>>> [0] >>>>>>> https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnEL= KeaY8 >>>>>>> _______________________________________________ >>>>>>> rtcweb mailing list >>>>>>> rtcweb@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>> >>>>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11352e4a2482ec05515fda99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's not an MMUSIC dependency, but JSEP relies on tric= kle-ice and trickle-ice relies on 5245bis, and there are definite technical= reasons for both of those dependencies.=C2=A0 So I don't see how JSEP = can avoid depending on 5245bis, at least indirectly.


On Mon, Jun 5, 2017 at 5:= 44 AM Eric Rescorla <ekr@rtfm.com>= ; wrote:
Do you ha= ve the names of those drafts to hand?

<= div class=3D"gmail_quote">On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andrease= n <fandreas@cisco.com> wrote:
Please note that we have several drafts in MMUSIC that normatively ref= erence 5245bis, and some of those drafts are RTCWeb dependencies AFAIK.

Thanks

-- Flemming (as MMUSIC co-chair)


On 5/22/17 6:52 PM, Cullen Jennings wrote:
Note that I don't think the timeline is the major issue (it is an issue= ) ... they key issue is that 5245bis does not seem to be needed for any tec= hnical reason by WebRTC.


On May 18, 2017, at 11:03 AM, Christer Holmberg <christer.holmberg@ericsson.com= > wrote:

Hi,

=C2=A0
In general, if people have issues with referencing 5245bis because they are= afraid it will hold up publication of RTCWEB specs, note that I have indic= ated to the ICE WG chairs that I think 5245bis is getting ready for WGLC.
=C2=A0
Regards,

=C2=A0
Christer

=C2=A0
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 18 May 2017 18:50
To: Sean Turner <sea= n@sn3rd.com>
Cc: RTCWeb IETF <rt= cweb@ietf.org>
Subject: Re: [rtcweb] Referring to 5245bis or 5245?

=C2=A0
Sean said:

=C2=A0
"draft-ietf-rtcweb-transports: Likewise, the chairs believer that a re= ference to RFC 5245 is also appropriate in transports.=C2=A0 This draft was= changed in version -17 to refer to 5245bis.=C2=A0 From GH: "The draft= s -bundle and -dualstack-fairness both depend on 5245bis according to Culle= n's chart in 'rtcweb-deps-13', and we already have a normative = dependency from -transport on these.=C2=A0 So consistency of the bundle is = improved by referencing 5245bis.".

[BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtc= web-transports which has a normative reference to draft-ietf-ice-dualstack-= fairness which in turn has a normative reference to draft-ietf-ice-rfc5245b= is.=C2=A0 So even if you remove the normative reference to RFC5245bis from = overview and transports, publication of overview will still be held up unti= l publication of RFC 5245bis, which will obsolete RFC 5245.

=C2=A0
On Thu, May 18, 2017 at 8:37 AM, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 11:35, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 10:54, Martin Thomson <martin.thomson@gmail.com> wrote:
I'm really confused about the statement regarding -transports.=C2=A0 Yo= u
say that 5245 is sufficient, then follow with justification for the
opposite position.
Sorry the change from 5425 to 5245bis was included in the latest version us= ing that rationale.=C2=A0 This shows to me that it was =E2=80=9Cnice=E2=80= =9D to get alignment and point to 5245bis not that it is necessary to point= 5245.=C2=A0 I.e., it=E2=80=99d be just fine to switch it back to referring= to 5245.
Whoops:

This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment and po= int to 5245bis not that it is necessary to point 5245bis.=C2=A0 I.e., it=E2= =80=99d be just fine to switch it back to referring to 5245.


If we have as large a dependency as bundle that refers to 5245bis,
then we are taking a transitive dependency on 5245bis and might as
well refer to that.

A lot of this comes down to what bundle says.=C2=A0 Now, I see that bundle<= br> depends on both 5245 and its -bis, which seems pretty inconsistent.=C2=A0 I=
don't immediately see any strong reason for bundle to refer to the
-bis, though it does refer to the ice-sip-sdp draft, which might be
sufficiently implicated as to make the change necessary.=C2=A0 We should ask Christer to confirm this.

I think that if we clarify that either way, then the reference in
-dualstack-fairness seems less of a concern; that document doesn't
need to reference 5245bis, though it would be nice if it could.
Exactly!

spt

On 18 May 2017 at 10:12, Sean Turner <sean@sn3rd.com> wrote:
ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised whether draf= ts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis.=C2=A0 We only nee= d to normatively refer to 5245bis if a technical part of 5245bis needs to b= e read and implemented in order to implement the referring draft.=C2=A0 We = have 7 drafts that refer to RFC 5245 and 2=C2=A0 that refer to draft-ietf-r= fc5245bis:

draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s discus= s position [0], the chairs believe that the reference to =E2=80=9CICE=E2=80= =9D in the ICE Agent definition should be to RFC 5245.

draft-ietf-rtcweb-transports: Likewise, the chairs believer that a referenc= e to RFC 5245 is also appropriate in transports.=C2=A0 This draft was chang= ed in version -17 to refer to 5245bis.=C2=A0 From GH: "The drafts -bun= dle and -dualstack-fairness both depend on 5245bis according to Cullen'= s chart in 'rtcweb-deps-13', and we already have a normative depend= ency from -transport on these.=C2=A0 So consistency of the bundle is improv= ed by referencing 5245bis."

spt

[0] https://mailarchive.ietf= .org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

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

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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--001a11352e4a2482ec05515fda99-- From nobody Wed Jun 7 09:10:34 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABE01267BB for ; Wed, 7 Jun 2017 09:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMZvFLxQzcsU for ; Wed, 7 Jun 2017 09:10:29 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC183129477 for ; Wed, 7 Jun 2017 09:10:27 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 63so5260964ywr.0 for ; Wed, 07 Jun 2017 09:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hQl5qMMR60BH2CAo+nQs9zKMnXFf/MrEYEIoitGN8og=; b=LzP/LUMCJgfe5rhrVF+BWVaCCUe9Qpbn+BCkDUMDk9qNUBrJgbQCTI4V0Oi1FHeU8F s4qDay6KAYoU6w4aqjDHpQxMVhvSgWOIEhj9jaNyZi5woQnzti7I/EiChHlfXPyrO1NC K5shf6EIfgeobaA3JhpUeVulr4NQsbC+CARVO3XJZMBlcZzzb7ZRCpN8xh7O61JcmP4k 0PVYeZ4LM4ad+DPPSiv7am6nUcMFPw/A2936684d0e+BJjGMiQS6Q261lpTmA67j4cHV blCR8GUmwLeyvT7doXS9Or/eqyj2U8sb+11k5iAMVt3zCU0hpsouWhhc+mBDcROflfTc DNfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hQl5qMMR60BH2CAo+nQs9zKMnXFf/MrEYEIoitGN8og=; b=V1dspuE+O/DmlZqDQlwUhU/vbmv1HS18xaXMCPjuWaEoosgZLqaIu2gOPmLe6Ia2YT IutMNkPRdIemKaU6P7u/X/cV/J2+yr+ZywckG8sLjT3O3YNEpzoJO3J5baZhxvSMlwS3 w3CQJog4LR7o/cObYL4RWMnozUV+ExmeH8lN03hz34z9XdJHeDwOjnRZQvGYK+m3FA3/ WLDuBXPSCHPwstAjCkDkUhkhFpaCzm4jOU74KLCZukxu1+EJ0VfZQLNXxdl0tTMhG0jN /Q9QF3eNMZF/eOqGFI6a88TtWsP1vfezQ0Eg6vDdYqxbvaC4ZwZ61Kb+of8jgvdIxggH ISGw== X-Gm-Message-State: AODbwcDyMZPzCnWSDoJbdN4mTZbsTBKXfRecMS6hLuO8F8QV775gzdYL 36Wq+ImwrS/bgqQcwvIPbIk0dZawXzk7 X-Received: by 10.129.172.39 with SMTP id k39mr7519121ywh.74.1496851826991; Wed, 07 Jun 2017 09:10:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.4 with HTTP; Wed, 7 Jun 2017 09:09:46 -0700 (PDT) In-Reply-To: References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> From: Eric Rescorla Date: Wed, 7 Jun 2017 18:09:46 +0200 Message-ID: To: Peter Thatcher Cc: Flemming Andreasen , "mmusic-chairs@tools.ietf.org" , RTCWeb IETF Content-Type: multipart/alternative; boundary="f403045e56ac6e27bd055160f96c" Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 16:10:33 -0000 --f403045e56ac6e27bd055160f96c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 7, 2017 at 4:49 PM, Peter Thatcher wrote= : > It's not an MMUSIC dependency, but JSEP relies on trickle-ice and > trickle-ice relies on 5245bis, and there are definite technical reasons f= or > both of those dependencies. > What's the reason for trickle depending on bis -Ekr > So I don't see how JSEP can avoid depending on 5245bis, at least > indirectly. > > > On Mon, Jun 5, 2017 at 5:44 AM Eric Rescorla wrote: > >> Do you have the names of those drafts to hand? >> >> On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen >> wrote: >> >>> Please note that we have several drafts in MMUSIC that normatively >>> reference 5245bis, and some of those drafts are RTCWeb dependencies AFA= IK. >>> >>> Thanks >>> >>> -- Flemming (as MMUSIC co-chair) >>> >>> >>> On 5/22/17 6:52 PM, Cullen Jennings wrote: >>> >>>> Note that I don't think the timeline is the major issue (it is an >>>> issue) ... they key issue is that 5245bis does not seem to be needed f= or >>>> any technical reason by WebRTC. >>>> >>>> >>>> On May 18, 2017, at 11:03 AM, Christer Holmberg < >>>>> christer.holmberg@ericsson.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> In general, if people have issues with referencing 5245bis because >>>>> they are afraid it will hold up publication of RTCWEB specs, note tha= t I >>>>> have indicated to the ICE WG chairs that I think 5245bis is getting r= eady >>>>> for WGLC. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Christer >>>>> >>>>> >>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard >>>>> Aboba >>>>> Sent: 18 May 2017 18:50 >>>>> To: Sean Turner >>>>> Cc: RTCWeb IETF >>>>> Subject: Re: [rtcweb] Referring to 5245bis or 5245? >>>>> >>>>> >>>>> Sean said: >>>>> >>>>> >>>>> "draft-ietf-rtcweb-transports: Likewise, the chairs believer that a >>>>> reference to RFC 5245 is also appropriate in transports. This draft = was >>>>> changed in version -17 to refer to 5245bis. From GH: "The drafts -bu= ndle >>>>> and -dualstack-fairness both depend on 5245bis according to Cullen's = chart >>>>> in 'rtcweb-deps-13', and we already have a normative dependency from >>>>> -transport on these. So consistency of the bundle is improved by >>>>> referencing 5245bis.". >>>>> >>>>> [BA] draft-ietf-rtcweb-overview has a normative reference to >>>>> draft-ietf-rtcweb-transports which has a normative reference to >>>>> draft-ietf-ice-dualstack-fairness which in turn has a normative >>>>> reference to draft-ietf-ice-rfc5245bis. So even if you remove the >>>>> normative reference to RFC5245bis from overview and transports, publi= cation >>>>> of overview will still be held up until publication of RFC 5245bis, w= hich >>>>> will obsolete RFC 5245. >>>>> >>>>> >>>>> On Thu, May 18, 2017 at 8:37 AM, Sean Turner wrote: >>>>> >>>>> >>>>> On May 18, 2017, at 11:35, Sean Turner wrote: >>>>>> >>>>>> >>>>>> On May 18, 2017, at 10:54, Martin Thomson >>>>>>> wrote: >>>>>>> >>>>>>> I'm really confused about the statement regarding -transports. You >>>>>>> say that 5245 is sufficient, then follow with justification for the >>>>>>> opposite position. >>>>>>> >>>>>> Sorry the change from 5425 to 5245bis was included in the latest >>>>>> version using that rationale. This shows to me that it was =E2=80= =9Cnice=E2=80=9D to get >>>>>> alignment and point to 5245bis not that it is necessary to point 524= 5. >>>>>> I.e., it=E2=80=99d be just fine to switch it back to referring to 52= 45. >>>>>> >>>>> Whoops: >>>>> >>>>> This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment = and point to >>>>> 5245bis not that it is necessary to point 5245bis. I.e., it=E2=80=99= d be just fine >>>>> to switch it back to referring to 5245. >>>>> >>>>> >>>>> If we have as large a dependency as bundle that refers to 5245bis, >>>>>>> then we are taking a transitive dependency on 5245bis and might as >>>>>>> well refer to that. >>>>>>> >>>>>>> A lot of this comes down to what bundle says. Now, I see that bund= le >>>>>>> depends on both 5245 and its -bis, which seems pretty inconsistent. >>>>>>> I >>>>>>> don't immediately see any strong reason for bundle to refer to the >>>>>>> -bis, though it does refer to the ice-sip-sdp draft, which might be >>>>>>> sufficiently implicated as to make the change necessary. We should >>>>>>> ask Christer to confirm this. >>>>>>> >>>>>>> I think that if we clarify that either way, then the reference in >>>>>>> -dualstack-fairness seems less of a concern; that document doesn't >>>>>>> need to reference 5245bis, though it would be nice if it could. >>>>>>> >>>>>> Exactly! >>>>>> >>>>>> spt >>>>>> >>>>>> On 18 May 2017 at 10:12, Sean Turner wrote: >>>>>>> >>>>>>>> ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised whe= ther >>>>>>>> drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. We = only need >>>>>>>> to normatively refer to 5245bis if a technical part of 5245bis nee= ds to be >>>>>>>> read and implemented in order to implement the referring draft. W= e have 7 >>>>>>>> drafts that refer to RFC 5245 and 2 that refer to draft-ietf-rfc5= 245bis: >>>>>>>> >>>>>>>> draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80= =99s >>>>>>>> discuss position [0], the chairs believe that the reference to =E2= =80=9CICE=E2=80=9D in the >>>>>>>> ICE Agent definition should be to RFC 5245. >>>>>>>> >>>>>>>> draft-ietf-rtcweb-transports: Likewise, the chairs believer that a >>>>>>>> reference to RFC 5245 is also appropriate in transports. This dra= ft was >>>>>>>> changed in version -17 to refer to 5245bis. From GH: "The drafts = -bundle >>>>>>>> and -dualstack-fairness both depend on 5245bis according to Cullen= 's chart >>>>>>>> in 'rtcweb-deps-13', and we already have a normative dependency fr= om >>>>>>>> -transport on these. So consistency of the bundle is improved by >>>>>>>> referencing 5245bis." >>>>>>>> >>>>>>>> spt >>>>>>>> >>>>>>>> [0] https://mailarchive.ietf.org/arch/msg/rtcweb/ >>>>>>>> GWdXRIO68FZwVtzzqugnELKeaY8 >>>>>>>> _______________________________________________ >>>>>>>> rtcweb mailing list >>>>>>>> rtcweb@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>> >>>>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>>> >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --f403045e56ac6e27bd055160f96c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 7, 2017 at 4:49 PM, Peter Thatcher <pthatcher@google.co= m> wrote:
= It's not an MMUSIC dependency, but JSEP relies on trickle-ice and trick= le-ice relies on 5245bis, and there are definite technical reasons for both= of those dependencies.=C2=A0

What= 9;s the reason for trickle depending on bis

-Ekr
=C2=A0
So I = don't see how JSEP can avoid depending on 5245bis, at least indirectly.=


On Mon, Jun 5, 2017 at 5:44 AM Eric Rescorla <ekr@rtfm.com> wrote:
Do you have the name= s of those drafts to hand?

On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen <fand= reas@cisco.com> wrote:
Plea= se note that we have several drafts in MMUSIC that normatively reference 52= 45bis, and some of those drafts are RTCWeb dependencies AFAIK.

Thanks

-- Flemming (as MMUSIC co-chair)


On 5/22/17 6:52 PM, Cullen Jennings wrote:
Note that I don't think the timeline is the major issue (it is an issue= ) ... they key issue is that 5245bis does not seem to be needed for any tec= hnical reason by WebRTC.


On May 18, 2017, at 11:03 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0
In general, if people have issues with referencing 5245bis because they are= afraid it will hold up publication of RTCWEB specs, note that I have indic= ated to the ICE WG chairs that I think 5245bis is getting ready for WGLC.
=C2=A0
Regards,

=C2=A0
Christer

=C2=A0
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 18 May 2017 18:50
To: Sean Turner <sea= n@sn3rd.com>
Cc: RTCWeb IETF <rt= cweb@ietf.org>
Subject: Re: [rtcweb] Referring to 5245bis or 5245?

=C2=A0
Sean said:

=C2=A0
"draft-ietf-rtcweb-transports: Likewise, the chairs believer that a re= ference to RFC 5245 is also appropriate in transports.=C2=A0 This draft was= changed in version -17 to refer to 5245bis.=C2=A0 From GH: "The draft= s -bundle and -dualstack-fairness both depend on 5245bis according to Culle= n's chart in 'rtcweb-deps-13', and we already have a normative = dependency from -transport on these.=C2=A0 So consistency of the bundle is = improved by referencing 5245bis.".

[BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtc= web-transports which has a normative reference to draft-ietf-ice-dualstack-= fairness which in turn has a normative reference to draft-ietf-ice-rfc= 5245bis.=C2=A0 So even if you remove the normative reference to RFC5245bis = from overview and transports, publication of overview will still be held up= until publication of RFC 5245bis, which will obsolete RFC 5245.

=C2=A0
On Thu, May 18, 2017 at 8:37 AM, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 11:35, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 10:54, Martin Thomson <martin.thomson@gmail.com> wrote:
I'm really confused about the statement regarding -transports.=C2=A0 Yo= u
say that 5245 is sufficient, then follow with justification for the
opposite position.
Sorry the change from 5425 to 5245bis was included in the latest version us= ing that rationale.=C2=A0 This shows to me that it was =E2=80=9Cnice=E2=80= =9D to get alignment and point to 5245bis not that it is necessary to point= 5245.=C2=A0 I.e., it=E2=80=99d be just fine to switch it back to referring= to 5245.
Whoops:

This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment and po= int to 5245bis not that it is necessary to point 5245bis.=C2=A0 I.e., it=E2= =80=99d be just fine to switch it back to referring to 5245.


If we have as large a dependency as bundle that refers to 5245bis,
then we are taking a transitive dependency on 5245bis and might as
well refer to that.

A lot of this comes down to what bundle says.=C2=A0 Now, I see that bundle<= br> depends on both 5245 and its -bis, which seems pretty inconsistent.=C2=A0 I=
don't immediately see any strong reason for bundle to refer to the
-bis, though it does refer to the ice-sip-sdp draft, which might be
sufficiently implicated as to make the change necessary.=C2=A0 We should ask Christer to confirm this.

I think that if we clarify that either way, then the reference in
-dualstack-fairness seems less of a concern; that document doesn't
need to reference 5245bis, though it would be nice if it could.
Exactly!

spt

On 18 May 2017 at 10:12, Sean Turner <sean@sn3rd.com> wrote:
ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised whether draf= ts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis.=C2=A0 We only nee= d to normatively refer to 5245bis if a technical part of 5245bis needs to b= e read and implemented in order to implement the referring draft.=C2=A0 We = have 7 drafts that refer to RFC 5245 and 2=C2=A0 that refer to draft-ietf-r= fc5245bis:

draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s discus= s position [0], the chairs believe that the reference to =E2=80=9CICE=E2=80= =9D in the ICE Agent definition should be to RFC 5245.

draft-ietf-rtcweb-transports: Likewise, the chairs believer that a referenc= e to RFC 5245 is also appropriate in transports.=C2=A0 This draft was chang= ed in version -17 to refer to 5245bis.=C2=A0 From GH: "The drafts -bun= dle and -dualstack-fairness both depend on 5245bis according to Cullen'= s chart in 'rtcweb-deps-13', and we already have a normative depend= ency from -transport on these.=C2=A0 So consistency of the bundle is improv= ed by referencing 5245bis."

spt

[0] https://mailarchive.ietf= .org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

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

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

--f403045e56ac6e27bd055160f96c-- From nobody Wed Jun 7 13:45:30 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B013148B for ; Wed, 7 Jun 2017 13:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9SAc0BoUjS8 for ; Wed, 7 Jun 2017 13:45:25 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC76F13148D for ; Wed, 7 Jun 2017 13:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27996; q=dns/txt; s=iport; t=1496868324; x=1498077924; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=+E7QKy4/fJtLcZkH2f1hBaoDyvBo08/xxqB8oA1iiXY=; b=P3cBEk26RML0H4pFNvBGx0rDNQY2h61irX6bVVS8GwE/8Ab0YHcdjih6 kMtxIt7FxKSlkXdDN9Aqnm/g2OOVnVPXU+/Qj8XaYFJlZL/btmbpWIVua kJc3ka3VI5NjV8/prEAFJIdcWhLeaF29Pful9JeJ9sVHp9gCiJqPOLBQd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAABhZThZ/40NJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm88LWKBDYNzihiRSCGIKo1WghAhAQyFLEoCgnU/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEBAwEBIUsLEAsOAwQBAQEgBwMCAiEGHwkIBg0GAgEBig8DCA0QA?= =?us-ascii?q?q52giYrhxUNhDIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZhgWArC4JqgliFJIJ?= =?us-ascii?q?hBZcHhnc7hyaDN4N+hF2CBoU+g0sjhk6LQoklHzg/S1EjFUaETjkcggEkNooBA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208,217";a="435394596" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jun 2017 20:45:23 +0000 Received: from [10.118.10.22] (rtp-fandreas-2-8815.cisco.com [10.118.10.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v57KjMoS026355; Wed, 7 Jun 2017 20:45:22 GMT To: Eric Rescorla References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> Cc: Cullen Jennings , Christer Holmberg , "mmusic-chairs@tools.ietf.org" , RTCWeb IETF From: Flemming Andreasen Message-ID: <3d52929e-a0f1-36d9-3361-93b875d355cc@cisco.com> Date: Wed, 7 Jun 2017 16:45:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5E61784C43B27CA2A52B5A49" Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:45:28 -0000 This is a multi-part message in MIME format. --------------5E61784C43B27CA2A52B5A49 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Based on https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/referencedby/ (or you can take a look at https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/): draft-ietf-mmusic-dtls-sdp draft-ietf-mmusic-ice-sip-sdp draft-ietf-mmusic-sdp-bundle-negotiation You will also have an issue with trickle-ice (and hence draft-ietf-mmusic-trickle-ice-sip). I think that's it from an MMUSIC point of view. Thanks -- Flemming On 6/5/17 8:43 AM, Eric Rescorla wrote: > Do you have the names of those drafts to hand? > > On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen > wrote: > > Please note that we have several drafts in MMUSIC that normatively > reference 5245bis, and some of those drafts are RTCWeb > dependencies AFAIK. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > On 5/22/17 6:52 PM, Cullen Jennings wrote: > > Note that I don't think the timeline is the major issue (it is > an issue) ... they key issue is that 5245bis does not seem to > be needed for any technical reason by WebRTC. > > > On May 18, 2017, at 11:03 AM, Christer Holmberg > > wrote: > > Hi, > > > In general, if people have issues with referencing 5245bis > because they are afraid it will hold up publication of > RTCWEB specs, note that I have indicated to the ICE WG > chairs that I think 5245bis is getting ready for WGLC. > > > Regards, > > > Christer > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org > ] On Behalf Of Bernard Aboba > Sent: 18 May 2017 18:50 > To: Sean Turner > > Cc: RTCWeb IETF > > Subject: Re: [rtcweb] Referring to 5245bis or 5245? > > > Sean said: > > > "draft-ietf-rtcweb-transports: Likewise, the chairs > believer that a reference to RFC 5245 is also appropriate > in transports. This draft was changed in version -17 to > refer to 5245bis. From GH: "The drafts -bundle and > -dualstack-fairness both depend on 5245bis according to > Cullen's chart in 'rtcweb-deps-13', and we already have a > normative dependency from -transport on these. So > consistency of the bundle is improved by referencing > 5245bis.". > > [BA] draft-ietf-rtcweb-overview has a normative reference > to draft-ietf-rtcweb-transports which has a normative > reference to draft-ietf-ice-dualstack-fairness which in > turn has a normative reference to > draft-ietf-ice-rfc5245bis. So even if you remove the > normative reference to RFC5245bis from overview and > transports, publication of overview will still be held up > until publication of RFC 5245bis, which will obsolete RFC > 5245. > > > On Thu, May 18, 2017 at 8:37 AM, Sean Turner > > wrote: > > > On May 18, 2017, at 11:35, Sean Turner > wrote: > > > On May 18, 2017, at 10:54, Martin Thomson > > wrote: > > I'm really confused about the statement regarding > -transports. You > say that 5245 is sufficient, then follow with > justification for the > opposite position. > > Sorry the change from 5425 to 5245bis was included in > the latest version using that rationale. This shows > to me that it was “nice” to get alignment and point to > 5245bis not that it is necessary to point 5245. I.e., > it’d be just fine to switch it back to referring to 5245. > > Whoops: > > This shows to me that it was “nice” to get alignment and > point to 5245bis not that it is necessary to point > 5245bis. I.e., it’d be just fine to switch it back to > referring to 5245. > > > If we have as large a dependency as bundle that > refers to 5245bis, > then we are taking a transitive dependency on > 5245bis and might as > well refer to that. > > A lot of this comes down to what bundle says. Now, > I see that bundle > depends on both 5245 and its -bis, which seems > pretty inconsistent. I > don't immediately see any strong reason for bundle > to refer to the > -bis, though it does refer to the ice-sip-sdp > draft, which might be > sufficiently implicated as to make the change > necessary. We should > ask Christer to confirm this. > > I think that if we clarify that either way, then > the reference in > -dualstack-fairness seems less of a concern; that > document doesn't > need to reference 5245bis, though it would be nice > if it could. > > Exactly! > > spt > > On 18 May 2017 at 10:12, Sean Turner > > wrote: > > ekr’s discuss on draft-ietf-rtcweb-overview > has raised whether drafts should refer to RFC > 5245 or draft-ietf-ice-rfc5245bis. We only > need to normatively refer to 5245bis if a > technical part of 5245bis needs to be read and > implemented in order to implement the > referring draft. We have 7 drafts that refer > to RFC 5245 and 2 that refer to > draft-ietf-rfc5245bis: > > draft-ietf-rtcweb-overview: As noted in my > response to ekr’s discuss position [0], the > chairs believe that the reference to “ICE” in > the ICE Agent definition should be to RFC 5245. > > draft-ietf-rtcweb-transports: Likewise, the > chairs believer that a reference to RFC 5245 > is also appropriate in transports. This draft > was changed in version -17 to refer to > 5245bis. From GH: "The drafts -bundle and > -dualstack-fairness both depend on 5245bis > according to Cullen's chart in > 'rtcweb-deps-13', and we already have a > normative dependency from -transport on > these. So consistency of the bundle is > improved by referencing 5245bis." > > spt > > [0] > https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --------------5E61784C43B27CA2A52B5A49 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Based on https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/referencedby/ (or you can take a look at https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/):

draft-ietf-mmusic-dtls-sdp

draft-ietf-mmusic-ice-sip-sdp

draft-ietf-mmusic-sdp-bundle-negotiation


You will also have an issue with trickle-ice (and hence draft-ietf-mmusic-trickle-ice-sip).

I think that's it from an MMUSIC point of view.


Thanks

-- Flemming


On 6/5/17 8:43 AM, Eric Rescorla wrote:
Do you have the names of those drafts to hand?

On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen <fandreas@cisco.com> wrote:
Please note that we have several drafts in MMUSIC that normatively reference 5245bis, and some of those drafts are RTCWeb dependencies AFAIK.

Thanks

-- Flemming (as MMUSIC co-chair)


On 5/22/17 6:52 PM, Cullen Jennings wrote:
Note that I don't think the timeline is the major issue (it is an issue) ... they key issue is that 5245bis does not seem to be needed for any technical reason by WebRTC.


On May 18, 2017, at 11:03 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

 
In general, if people have issues with referencing 5245bis because they are afraid it will hold up publication of RTCWEB specs, note that I have indicated to the ICE WG chairs that I think 5245bis is getting ready for WGLC.

 
Regards,

 
Christer

 
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 18 May 2017 18:50
To: Sean Turner <sean@sn3rd.com>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Referring to 5245bis or 5245?

 
Sean said:

 
"draft-ietf-rtcweb-transports: Likewise, the chairs believer that a reference to RFC 5245 is also appropriate in transports.  This draft was changed in version -17 to refer to 5245bis.  From GH: "The drafts -bundle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a normative dependency from -transport on these.  So consistency of the bundle is improved by referencing 5245bis.".

[BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtcweb-transports which has a normative reference to draft-ietf-ice-dualstack-fairness which in turn has a normative reference to draft-ietf-ice-rfc5245bis.  So even if you remove the normative reference to RFC5245bis from overview and transports, publication of overview will still be held up until publication of RFC 5245bis, which will obsolete RFC 5245.

 
On Thu, May 18, 2017 at 8:37 AM, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 11:35, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 10:54, Martin Thomson <martin.thomson@gmail.com> wrote:

I'm really confused about the statement regarding -transports.  You
say that 5245 is sufficient, then follow with justification for the
opposite position.
Sorry the change from 5425 to 5245bis was included in the latest version using that rationale.  This shows to me that it was “nice” to get alignment and point to 5245bis not that it is necessary to point 5245.  I.e., it’d be just fine to switch it back to referring to 5245.
Whoops:

This shows to me that it was “nice” to get alignment and point to 5245bis not that it is necessary to point 5245bis.  I.e., it’d be just fine to switch it back to referring to 5245.


If we have as large a dependency as bundle that refers to 5245bis,
then we are taking a transitive dependency on 5245bis and might as
well refer to that.

A lot of this comes down to what bundle says.  Now, I see that bundle
depends on both 5245 and its -bis, which seems pretty inconsistent.  I
don't immediately see any strong reason for bundle to refer to the
-bis, though it does refer to the ice-sip-sdp draft, which might be
sufficiently implicated as to make the change necessary.  We should
ask Christer to confirm this.

I think that if we clarify that either way, then the reference in
-dualstack-fairness seems less of a concern; that document doesn't
need to reference 5245bis, though it would be nice if it could.
Exactly!

spt

On 18 May 2017 at 10:12, Sean Turner <sean@sn3rd.com> wrote:
ekr’s discuss on draft-ietf-rtcweb-overview has raised whether drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis.  We only need to normatively refer to 5245bis if a technical part of 5245bis needs to be read and implemented in order to implement the referring draft.  We have 7 drafts that refer to RFC 5245 and 2  that refer to draft-ietf-rfc5245bis:

draft-ietf-rtcweb-overview: As noted in my response to ekr’s discuss position [0], the chairs believe that the reference to “ICE” in the ICE Agent definition should be to RFC 5245.

draft-ietf-rtcweb-transports: Likewise, the chairs believer that a reference to RFC 5245 is also appropriate in transports.  This draft was changed in version -17 to refer to 5245bis.  From GH: "The drafts -bundle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a normative dependency from -transport on these.  So consistency of the bundle is improved by referencing 5245bis."

spt

[0] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

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

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


--------------5E61784C43B27CA2A52B5A49-- From nobody Wed Jun 7 19:39:40 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE39129420 for ; Wed, 7 Jun 2017 19:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IRFwv-hetuO for ; Wed, 7 Jun 2017 19:39:36 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B661200F1 for ; Wed, 7 Jun 2017 19:39:36 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id 4so6803358ybl.1 for ; Wed, 07 Jun 2017 19:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h/KYlaMMq11Qdb9OiXJDjBbcl0PQx72W4A9oNpnE0sY=; b=KOSl8PP/PHOUYlH59iJnnqZfipU5LQ/UbQlFFDf/Z9TizZErBu9QyfzNI21z1/B9X2 UL6Z7j/Ey4KMwL60OpWcZJut59x40dANazB4tTcDW2gNpDrbHrSbEvtFACbtGNqbWkXg xCauPzSG2STdmE0dhjSWegQ9PrLrA6vApEGQ2bJxB+Jk+8OFKsikkAHfnJqvZzSCTEZC 3QDYOGb8SPPod2az4R0MoGOKuNSBTW5S50EyU17qPJIrnIbfriB2ndXRwVNFTjeRhWxn aTwZvOWLUind8LwlBAKb6SDFHnS0LPAq3orZUnp2oMyYNlUEnSNhcZWOYIjfRaravBWV 96uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h/KYlaMMq11Qdb9OiXJDjBbcl0PQx72W4A9oNpnE0sY=; b=FXZTkNvtmbXki3nXJKuulHtGbj8sJLAlGYQEDI2qJykHnKQkSYnrTBVhFI9+I+fqEj B2fZ+DqC6oVE0Nq+eJniwIHaDbXv9GEOi+pGHSR3TBZY03ZoV1RN3lNznrLypg4R8HPX 9/BTSQVcxjBNyBPkFAjFcklvnsjplSw9q7jjtfPmNueQWhG9dXQ2fYBqQwhwGIm6zEsM uXVQVPMY/kHeWQhH1EsqXUldETrQzSwCGRnYEE5BheDOgu2w+NaDf9RQWGdEoRUTGCXI mig3IDKCyHDcgareJDQMcVQl1J3zlNa1X2blx5Y6boSfnI5NP93jog2ofscRTikTWQFJ dCwQ== X-Gm-Message-State: AODbwcDB30IvRNWAq9/Ot1vXx3/PThwMsYLk1/kl0KquOMkm3E2ICR/I vLwpbCvo/P7T7GGijyjMiqRdzfAfX71J X-Received: by 10.37.68.87 with SMTP id r84mr9462607yba.229.1496889575245; Wed, 07 Jun 2017 19:39:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.4 with HTTP; Wed, 7 Jun 2017 19:38:54 -0700 (PDT) In-Reply-To: <3d52929e-a0f1-36d9-3361-93b875d355cc@cisco.com> References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> <3d52929e-a0f1-36d9-3361-93b875d355cc@cisco.com> From: Eric Rescorla Date: Thu, 8 Jun 2017 04:38:54 +0200 Message-ID: To: Flemming Andreasen Cc: Cullen Jennings , Christer Holmberg , "mmusic-chairs@tools.ietf.org" , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a113f5f3e669a98055169c363" Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 02:39:39 -0000 --001a113f5f3e669a98055169c363 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 7, 2017 at 10:45 PM, Flemming Andreasen wrote: > Based on https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ > referencedby/ (or you can take a look at https://datatracker.ietf.org/ > doc/draft-jennings-rtcweb-deps/): > > draft-ietf-mmusic-dtls-sdp > > > draft-ietf-mmusic-ice-sip-sdp > > > draft-ietf-mmusic-sdp-bundle-negotiation > > I don't see why any of these would require ICE-bis except through trickle. I appreciate that the document reference graph shows a lot of dependencies on ICE-bis, but what's not clear to me is what the *technical* dependencies are. -Ekr > > > > You will also have an issue with trickle-ice (and hence > draft-ietf-mmusic-trickle-ice-sip). > > I think that's it from an MMUSIC point of view. > > > Thanks > > -- Flemming > > > On 6/5/17 8:43 AM, Eric Rescorla wrote: > > Do you have the names of those drafts to hand? > > On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen > wrote: > >> Please note that we have several drafts in MMUSIC that normatively >> reference 5245bis, and some of those drafts are RTCWeb dependencies AFAI= K. >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> >> On 5/22/17 6:52 PM, Cullen Jennings wrote: >> >>> Note that I don't think the timeline is the major issue (it is an issue= ) >>> ... they key issue is that 5245bis does not seem to be needed for any >>> technical reason by WebRTC. >>> >>> >>> On May 18, 2017, at 11:03 AM, Christer Holmberg < >>>> christer.holmberg@ericsson.com> wrote: >>>> >>>> Hi, >>>> >>>> >>>> In general, if people have issues with referencing 5245bis because the= y >>>> are afraid it will hold up publication of RTCWEB specs, note that I ha= ve >>>> indicated to the ICE WG chairs that I think 5245bis is getting ready f= or >>>> WGLC. >>>> >>>> >>>> Regards, >>>> >>>> >>>> Christer >>>> >>>> >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard >>>> Aboba >>>> Sent: 18 May 2017 18:50 >>>> To: Sean Turner >>>> Cc: RTCWeb IETF >>>> Subject: Re: [rtcweb] Referring to 5245bis or 5245? >>>> >>>> >>>> Sean said: >>>> >>>> >>>> "draft-ietf-rtcweb-transports: Likewise, the chairs believer that a >>>> reference to RFC 5245 is also appropriate in transports. This draft w= as >>>> changed in version -17 to refer to 5245bis. From GH: "The drafts -bun= dle >>>> and -dualstack-fairness both depend on 5245bis according to Cullen's c= hart >>>> in 'rtcweb-deps-13', and we already have a normative dependency from >>>> -transport on these. So consistency of the bundle is improved by >>>> referencing 5245bis.". >>>> >>>> [BA] draft-ietf-rtcweb-overview has a normative reference to >>>> draft-ietf-rtcweb-transports which has a normative reference to >>>> draft-ietf-ice-dualstack-fairness which in turn has a normative >>>> reference to draft-ietf-ice-rfc5245bis. So even if you remove the >>>> normative reference to RFC5245bis from overview and transports, public= ation >>>> of overview will still be held up until publication of RFC 5245bis, wh= ich >>>> will obsolete RFC 5245. >>>> >>>> >>>> On Thu, May 18, 2017 at 8:37 AM, Sean Turner wrote: >>>> >>>> >>>> On May 18, 2017, at 11:35, Sean Turner wrote: >>>>> >>>>> >>>>> On May 18, 2017, at 10:54, Martin Thomson >>>>>> wrote: >>>>>> >>>>>> I'm really confused about the statement regarding -transports. You >>>>>> say that 5245 is sufficient, then follow with justification for the >>>>>> opposite position. >>>>>> >>>>> Sorry the change from 5425 to 5245bis was included in the latest >>>>> version using that rationale. This shows to me that it was =E2=80=9C= nice=E2=80=9D to get >>>>> alignment and point to 5245bis not that it is necessary to point 5245= . >>>>> I.e., it=E2=80=99d be just fine to switch it back to referring to 524= 5. >>>>> >>>> Whoops: >>>> >>>> This shows to me that it was =E2=80=9Cnice=E2=80=9D to get alignment a= nd point to >>>> 5245bis not that it is necessary to point 5245bis. I.e., it=E2=80=99d= be just fine >>>> to switch it back to referring to 5245. >>>> >>>> >>>> If we have as large a dependency as bundle that refers to 5245bis, >>>>>> then we are taking a transitive dependency on 5245bis and might as >>>>>> well refer to that. >>>>>> >>>>>> A lot of this comes down to what bundle says. Now, I see that bundl= e >>>>>> depends on both 5245 and its -bis, which seems pretty inconsistent. = I >>>>>> don't immediately see any strong reason for bundle to refer to the >>>>>> -bis, though it does refer to the ice-sip-sdp draft, which might be >>>>>> sufficiently implicated as to make the change necessary. We should >>>>>> ask Christer to confirm this. >>>>>> >>>>>> I think that if we clarify that either way, then the reference in >>>>>> -dualstack-fairness seems less of a concern; that document doesn't >>>>>> need to reference 5245bis, though it would be nice if it could. >>>>>> >>>>> Exactly! >>>>> >>>>> spt >>>>> >>>>> On 18 May 2017 at 10:12, Sean Turner wrote: >>>>>> >>>>>>> ekr=E2=80=99s discuss on draft-ietf-rtcweb-overview has raised whet= her >>>>>>> drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis. We o= nly need >>>>>>> to normatively refer to 5245bis if a technical part of 5245bis need= s to be >>>>>>> read and implemented in order to implement the referring draft. We= have 7 >>>>>>> drafts that refer to RFC 5245 and 2 that refer to draft-ietf-rfc52= 45bis: >>>>>>> >>>>>>> draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99= s discuss >>>>>>> position [0], the chairs believe that the reference to =E2=80=9CICE= =E2=80=9D in the ICE >>>>>>> Agent definition should be to RFC 5245. >>>>>>> >>>>>>> draft-ietf-rtcweb-transports: Likewise, the chairs believer that a >>>>>>> reference to RFC 5245 is also appropriate in transports. This draf= t was >>>>>>> changed in version -17 to refer to 5245bis. From GH: "The drafts -= bundle >>>>>>> and -dualstack-fairness both depend on 5245bis according to Cullen'= s chart >>>>>>> in 'rtcweb-deps-13', and we already have a normative dependency fro= m >>>>>>> -transport on these. So consistency of the bundle is improved by >>>>>>> referencing 5245bis." >>>>>>> >>>>>>> spt >>>>>>> >>>>>>> [0] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtz >>>>>>> zqugnELKeaY8 >>>>>>> _______________________________________________ >>>>>>> rtcweb mailing list >>>>>>> rtcweb@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>> >>>>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > --001a113f5f3e669a98055169c363 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 7, 2017 at 10:45 PM, Flemming Andreasen &= lt;fandreas@cisco.c= om> wrote:
=20 =20 =20

I don&= #39;t see why any of these would require ICE-bis except through trickle.

I appreciate that the document reference graph shows= a lot of dependencies on ICE-bis, but what's not clear to me is what t= he *technical* dependencies are.
-Ekr
=C2=A0



You will also have an issue with trickle-ice (and hence draft-ietf-mmusic-trickle-ice-sip).

I think that's it from an MMUSIC point of view.


Thanks

-- Flemming


On 6/5/17 8:43 AM, = Eric Rescorla wrote:
=20
Do you have the names of those drafts to hand?

On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen <fandreas@cisco.com> wrote:
Please note that we have several drafts in MMUSIC that normatively reference 5245bis, and some of those drafts are RTCWeb dependencies AFAIK.

Thanks

-- Flemming (as MMUSIC co-chair)


On 5/22/17 6:52 PM, Cullen Jennings wrote:
Note that I don't think the timeline is the major issue (it is an issue) ... they key issue is that 5245bis does not seem to be needed for any technical reason by WebRTC.


On May 18, 2017, at 11:03 AM, Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:

Hi,

=C2=A0
In general, if people have issues with referencing 5245bis because they are afraid it will hold up publication of RTCWEB specs, note that I have indicated to the ICE WG chairs that I think 5245bis is getting ready for WGLC.

=C2=A0
Regards,

=C2=A0
Christer

=C2=A0
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 18 May 2017 18:50
To: Sean Turner <sean@sn3rd.com>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Referring to 5245bis or 5245?

=C2=A0
Sean said:

=C2=A0
"draft-ietf-rtcweb-transports: Likewise, the chair= s believer that a reference to RFC 5245 is also appropriate in transports.=C2=A0 This draft was changed in version -17 to refer to 5245bis.=C2=A0 From GH: &quo= t;The drafts -bundle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a normati= ve dependency from -transport on these.=C2=A0 So consisten= cy of the bundle is improved by referencing 5245bis."= .

[BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtcweb-transports which has a normative reference to draft-ietf-ice-dualstack-fairness which in turn has a normative reference to draft-ietf-ice-rfc5245bis.=C2=A0 So even if you remove the normative reference to RFC5245bis from overview and transports, publication of overview will still be held up until publication of RFC 5245bis, which will obsolete RFC 5245.

=C2=A0
On Thu, May 18, 2017 at 8:37 AM, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 11:35, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 10:54, Martin Thomson <martin.thomson@gma= il.com> wrote:

I'm really confused about the statement regarding -transports.=C2=A0 You
say that 5245 is sufficient, then follow with justification for the
opposite position.
Sorry the change from 5425 to 5245bis was included in the latest version using that rationale.=C2=A0 Thi= s shows to me that it was =E2=80=9Cnice=E2=80=9D to get= alignment and point to 5245bis not that it is necessary to point 5245.=C2=A0 I.e., it=E2=80=99d be just fine to = switch it back to referring to 5245.
Whoops:

This shows to me that it was =E2=80=9Cnice=E2=80=9D to = get alignment and point to 5245bis not that it is necessary to point 5245bis.=C2=A0 I.e., it=E2=80=99d be just fine to= switch it back to referring to 5245.


If we have as large a dependency as bundle that refers to 5245bis,
then we are taking a transitive dependency on 5245bis and might as
well refer to that.

A lot of this comes down to what bundle says.=C2=A0 Now, I see that bundle
depends on both 5245 and its -bis, which seems pretty inconsistent.=C2=A0 I
don't immediately see any strong reason for bundle to refer to the
-bis, though it does refer to the ice-sip-sdp draft, which might be
sufficiently implicated as to make the change necessary.=C2=A0 We should
ask Christer to confirm this.

I think that if we clarify that either way, then the reference in
-dualstack-fairness seems less of a concern; that document doesn't
need to reference 5245bis, though it would be nice if it could.
Exactly!

spt

On 18 May 2017 at 10:12, Sean Turner <sean@sn3rd.com> wrote:
ekr=E2=80=99s discuss on draft-ietf-rtcweb-overvi= ew has raised whether drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis.=C2=A0 We only need to normatively refer to 5245bis if a technical part of 5245bis needs to be read and implemented in order to implement the referring draft.=C2=A0 We have 7 drafts that refe= r to RFC 5245 and 2=C2=A0 that refer to draft-ietf-rfc5245bis:

draft-ietf-rtcweb-overview: As noted in my response to ekr=E2=80=99s discuss position [0], t= he chairs believe that the reference to =E2=80=9CICE= =E2=80=9D in the ICE Agent definition should be to RFC 5245.

draft-ietf-rtcweb-transports: Likewise, the chairs believer that a reference to RFC 5245 is also appropriate in transports.=C2=A0 This dra= ft was changed in version -17 to refer to 5245bis.=C2=A0 From GH: "The drafts -bundle = and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a normative dependency from -transport on these.=C2=A0 So consistency of the bundle is improved by referencing 5245bis."

spt

[0] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqu= gnELKeaY8
____________________________________________= ___
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/l= istinfo/rtcweb
_______________________________________________ rtcweb mailing list
rt= cweb@ietf.org
https://www.ietf.org/mailman/li= stinfo/rtcweb

=C2=A0
_______________________________________________ rtcweb mailing list
rt= cweb@ietf.org
https://www.ietf.org/mailman/li= stinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcw= eb@ietf.org
https://www.ietf.org/mailman/list= info/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb= @ietf.org
https://www.ietf.org/mailman/listin= fo/rtcweb



--001a113f5f3e669a98055169c363-- From nobody Thu Jun 8 00:21:16 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB685127077 for ; Thu, 8 Jun 2017 00:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 87Io5fRUU326 for ; Thu, 8 Jun 2017 00:21:11 -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 3CE52120725 for ; Thu, 8 Jun 2017 00:21:11 -0700 (PDT) X-AuditID: c1b4fb2d-ef7ff7000000080d-41-5938fae414a1 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.57.02061.4EAF8395; Thu, 8 Jun 2017 09:21:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Thu, 8 Jun 2017 09:21:12 +0200 From: Christer Holmberg To: Eric Rescorla , Flemming Andreasen CC: Cullen Jennings , "mmusic-chairs@tools.ietf.org" , RTCWeb IETF Thread-Topic: [rtcweb] Referring to 5245bis or 5245? Thread-Index: AQHSz+GnKDPh4DvzQUm5jwEPYC4blKH6DACAgAALZoCAAAC4gIAAFDsAgAAkh7CABon8gIAQr1CAgASnVYCAA6srAIAAYsYAgACC9oA= Date: Thu, 8 Jun 2017 07:21:11 +0000 Message-ID: References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> <3d52929e-a0f1-36d9-3361-93b875d355cc@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D55ED6091DFE0christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUyM2K7iu7TXxaRBl8/SVqseH2O3eL9BV2L D+t/MFr825tksfZfO7sDq8eU3xtZPZYs+cnkcfn8R0aPyY/bmD2+XP7MFsAaxWWTkpqTWZZa pG+XwJXxY/tk1oLvOxkrjq7tZm9g/L2AsYuRk0NCwESir/8akM3FISRwhFFi6pIHLBDOIkaJ h6fambsYOTjYBCwkuv9pg5giAp4SV+77gZQwCzQzSpw7184GMkhYwFji/dGlYLYI0NA7f9Yy QthlEutW3GYBsVkEVCT+XvjLCmLzClhLXGnvhVo8g1Vi8aTDYM2cAoESe6eeZQexGQXEJL6f WsMEYjMLiEvcejKfCeJqAYkle84zQ9iiEi8f/2MFOU5UQE/i3X5PiLCixMdX+xghWhMklkxc xAyxV1Di5MwnLBMYRWchmToLSdksJGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45yzgLaDMz0DtL b0giK1nAyLGKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzCCD275rbuDcfVrx0OMAhyMSjy8 +j8sIoVYE8uKK3MPMUpwMCuJ8LK/AgrxpiRWVqUW5ccXleakFh9ilOZgURLnddh3IUJIID2x JDU7NbUgtQgmy8TBKdXA6HpgXew2dcXPzx4vYZknnGVfX9P4Ym7wVos7MTv2SSqxxTYbrDkY ZLC7f2PLCpFZN3vkzmu/7lk1//TR1dM9Zmw67Xxf5PoUh9Ki+bdNt9Z/l3rwpylz/i/Vg0eP /ZT67NzhN7/kokjr6ilfYx6vM9rV3p+lM8v2/N2X7RUPP/1jTMhlYnihd16JpTgj0VCLuag4 EQCuPDDJ3AIAAA== Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 07:21:15 -0000 --_000_D55ED6091DFE0christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I think one question is what is meant by =93technical=94. As I=92ve said before, most (if not all) of the non-editorial changes in 52= 45bis have been done based on claims (mostly from the RTCWEB community!) th= at there are features in legacy ICE that don=92t work good, can cause conge= stion etc. So, while legacy ICE may not be broken, in my opinion the change= s in 5245bis for sure are more than "nice-to-have" ones. Regards, Christer From: Eric Rescorla > Date: Thursday 8 June 2017 at 05:38 To: Flemming Andreasen > Cc: Cullen Jennings >, Christer Holmber= g >, = "mmusic-chairs@tools.ietf.org" >, "rtcweb@ietf.= org" > Subject: Re: [rtcweb] Referring to 5245bis or 5245? On Wed, Jun 7, 2017 at 10:45 PM, Flemming Andreasen > wrote: Based on https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/referen= cedby/ (or you can take a look at https://datatracker.ietf.org/doc/draft-je= nnings-rtcweb-deps/): draft-ietf-mmusic-dtls-sdp draft-ietf-mmusic-ice-sip-sdp draft-ietf-mmusic-sdp-bundle-negotiation I don't see why any of these would require ICE-bis except through trickle. I appreciate that the document reference graph shows a lot of dependencies = on ICE-bis, but what's not clear to me is what the *technical* dependencies= are. -Ekr You will also have an issue with trickle-ice (and hence draft-ietf-mmusic-t= rickle-ice-sip). I think that's it from an MMUSIC point of view. Thanks -- Flemming On 6/5/17 8:43 AM, Eric Rescorla wrote: Do you have the names of those drafts to hand? On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen > wrote: Please note that we have several drafts in MMUSIC that normatively referenc= e 5245bis, and some of those drafts are RTCWeb dependencies AFAIK. Thanks -- Flemming (as MMUSIC co-chair) On 5/22/17 6:52 PM, Cullen Jennings wrote: Note that I don't think the timeline is the major issue (it is an issue) ..= . they key issue is that 5245bis does not seem to be needed for any technic= al reason by WebRTC. On May 18, 2017, at 11:03 AM, Christer Holmberg > wrote: Hi, In general, if people have issues with referencing 5245bis because they are= afraid it will hold up publication of RTCWEB specs, note that I have indic= ated to the ICE WG chairs that I think 5245bis is getting ready for WGLC. Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: 18 May 2017 18:50 To: Sean Turner > Cc: RTCWeb IETF > Subject: Re: [rtcweb] Referring to 5245bis or 5245? Sean said: "draft-ietf-rtcweb-transports: Likewise, the chairs believer that a referen= ce to RFC 5245 is also appropriate in transports. This draft was changed i= n version -17 to refer to 5245bis. From GH: "The drafts -bundle and -duals= tack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb= -deps-13', and we already have a normative dependency from -transport on th= ese. So consistency of the bundle is improved by referencing 5245bis.". [BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtc= web-transports which has a normative reference to draft-ietf-ice-dualstack-= fairness which in turn has a normative reference to draft-ietf-ice-rfc5245b= is. So even if you remove the normative reference to RFC5245bis from overv= iew and transports, publication of overview will still be held up until pub= lication of RFC 5245bis, which will obsolete RFC 5245. On Thu, May 18, 2017 at 8:37 AM, Sean Turner > wrote: On May 18, 2017, at 11:35, Sean Turner > wrote: On May 18, 2017, at 10:54, Martin Thomson > wrote: I'm really confused about the statement regarding -transports. You say that 5245 is sufficient, then follow with justification for the opposite position. Sorry the change from 5425 to 5245bis was included in the latest version us= ing that rationale. This shows to me that it was =93nice=94 to get alignme= nt and point to 5245bis not that it is necessary to point 5245. I.e., it= =92d be just fine to switch it back to referring to 5245. Whoops: This shows to me that it was =93nice=94 to get alignment and point to 5245b= is not that it is necessary to point 5245bis. I.e., it=92d be just fine to= switch it back to referring to 5245. If we have as large a dependency as bundle that refers to 5245bis, then we are taking a transitive dependency on 5245bis and might as well refer to that. A lot of this comes down to what bundle says. Now, I see that bundle depends on both 5245 and its -bis, which seems pretty inconsistent. I don't immediately see any strong reason for bundle to refer to the -bis, though it does refer to the ice-sip-sdp draft, which might be sufficiently implicated as to make the change necessary. We should ask Christer to confirm this. I think that if we clarify that either way, then the reference in -dualstack-fairness seems less of a concern; that document doesn't need to reference 5245bis, though it would be nice if it could. Exactly! spt On 18 May 2017 at 10:12, Sean Turner = > wrote: ekr=92s discuss on draft-ietf-rtcweb-overview has raised whether drafts sho= uld refer to RFC 5245 or draft-ietf-ice-rfc5245bis. We only need to normat= ively refer to 5245bis if a technical part of 5245bis needs to be read and = implemented in order to implement the referring draft. We have 7 drafts th= at refer to RFC 5245 and 2 that refer to draft-ietf-rfc5245bis: draft-ietf-rtcweb-overview: As noted in my response to ekr=92s discuss posi= tion [0], the chairs believe that the reference to =93ICE=94 in the ICE Age= nt definition should be to RFC 5245. draft-ietf-rtcweb-transports: Likewise, the chairs believer that a referenc= e to RFC 5245 is also appropriate in transports. This draft was changed in= version -17 to refer to 5245bis. From GH: "The drafts -bundle and -dualst= ack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-= deps-13', and we already have a normative dependency from -transport on the= se. So consistency of the bundle is improved by referencing 5245bis." spt [0] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY= 8 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_D55ED6091DFE0christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <540CCBE23A8DD347A2492C621BAFDDB1@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I think one question is what is meant by =93technical=94.

As I=92ve said before, most (if not all) of the non-editorial changes = in 5245bis have been done based on claims (mostly from the RTCWEB community= !) that there are features in legacy ICE that don=92t work good, can cause = congestion etc. So, while legacy ICE may not be broken, in my opinion the changes in 5245bis for sure are more = than "nice-to-have" ones.

Regards,

Christer

From: Eric Rescorla <ekr@rtfm.com>
Date: Thursday 8 June 2017 at 05:38=
To: Flemming Andreasen <fandreas@cisco.com>
Cc: Cullen Jennings <fluffy@iii.ca>, Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic-chairs= @tools.ietf.org" <mmusic-chairs@tools.ie= tf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Referring to = 5245bis or 5245?



On Wed, Jun 7, 2017 at 10:45 PM, Flemming Andrea= sen <fandreas@cisco.= com> wrote:

I don't see why any of these would require ICE-bis except through tric= kle.

I appreciate that the document reference graph shows a lot of dependen= cies on ICE-bis, but what's not clear to me is what the *technical* depende= ncies are.
-Ekr
 



You will also have an issue with trickle-ice (and hence draft-ietf-mmusic-t= rickle-ice-sip).

I think that's it from an MMUSIC point of view.


Thanks

-- Flemming


On 6/5/17 8:43 AM, Eric= Rescorla wrote:
Do you have the names of those drafts to hand?

On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreas= en <fandreas@cisco.= com> wrote:
Please note that we have several drafts in MMUSIC that normatively referenc= e 5245bis, and some of those drafts are RTCWeb dependencies AFAIK.

Thanks

-- Flemming (as MMUSIC co-chair)


On 5/22/17 6:52 PM, Cullen Jennings wrote:
Note that I don't think the timeline is the major issue (it is an issue) ..= . they key issue is that 5245bis does not seem to be needed for any technic= al reason by WebRTC.


On May 18, 2017, at 11:03 AM, Christer Holmberg <christer.holmberg@ericsson.co<= wbr>m> wrote:

Hi,

 
In general, if people have issues with referencing 5245bis because they are= afraid it will hold up publication of RTCWEB specs, note that I have indic= ated to the ICE WG chairs that I think 5245bis is getting ready for WGLC.
 
Regards,

 
Christer

 
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 18 May 2017 18:50
To: Sean Turner <sea= n@sn3rd.com>
Cc: RTCWeb IETF <rt= cweb@ietf.org>
Subject: Re: [rtcweb] Referring to 5245bis or 5245?

 
Sean said:

 
"draft-ietf-rtcweb-transports: Likewise, the chairs believer that a re= ference to RFC 5245 is also appropriate in transports.  This draft was= changed in version -17 to refer to 5245bis.  From GH: "The draft= s -bundle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a nor= mative dependency from -transport on these.  So consistency of the bun= dle is improved by referencing 5245bis.".

[BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtc= web-transports which has a normative reference to draft-ietf-ice-dualstack-= fairness which in turn has a normative reference to draft-ietf-ice-rfc= 5245bis.  So even if you remove the normative reference to RFC5245bis from overview and transports, public= ation of overview will still be held up until publication of RFC 5245bis, w= hich will obsolete RFC 5245.

 
On Thu, May 18, 2017 at 8:37 AM, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 11:35, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 10:54, Martin Thomson <martin.thomson@gmail.com> wrote:
I'm really confused about the statement regarding -transports.  You say that 5245 is sufficient, then follow with justification for the
opposite position.
Sorry the change from 5425 to 5245bis was included in the latest version us= ing that rationale.  This shows to me that it was =93nice=94 to get al= ignment and point to 5245bis not that it is necessary to point 5245.  = I.e., it=92d be just fine to switch it back to referring to 5245.
Whoops:

This shows to me that it was =93nice=94 to get alignment and point to 5245b= is not that it is necessary to point 5245bis.  I.e., it=92d be just fi= ne to switch it back to referring to 5245.


If we have as large a dependency as bundle that refers to 5245bis,
then we are taking a transitive dependency on 5245bis and might as
well refer to that.

A lot of this comes down to what bundle says.  Now, I see that bundle<= br> depends on both 5245 and its -bis, which seems pretty inconsistent.  I=
don't immediately see any strong reason for bundle to refer to the
-bis, though it does refer to the ice-sip-sdp draft, which might be
sufficiently implicated as to make the change necessary.  We should ask Christer to confirm this.

I think that if we clarify that either way, then the reference in
-dualstack-fairness seems less of a concern; that document doesn't
need to reference 5245bis, though it would be nice if it could.
Exactly!

spt

On 18 May 2017 at 10:12, Sean Turner <sean@sn3rd.com> wrote:
ekr=92s discuss on draft-ietf-rtcweb-overview has raised whether drafts sho= uld refer to RFC 5245 or draft-ietf-ice-rfc5245bis.  We only need to n= ormatively refer to 5245bis if a technical part of 5245bis needs to be read= and implemented in order to implement the referring draft.  We have 7 drafts that refer to RFC 5245 and 2&n= bsp; that refer to draft-ietf-rfc5245bis:

draft-ietf-rtcweb-overview: As noted in my response to ekr=92s discuss posi= tion [0], the chairs believe that the reference to =93ICE=94 in the ICE Age= nt definition should be to RFC 5245.

draft-ietf-rtcweb-transports: Likewise, the chairs believer that a referenc= e to RFC 5245 is also appropriate in transports.  This draft was chang= ed in version -17 to refer to 5245bis.  From GH: "The drafts -bun= dle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a nor= mative dependency from -transport on these.  So consistency of the bun= dle is improved by referencing 5245bis."

spt

[0] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugn= ELKeaY8
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
 
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

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



--_000_D55ED6091DFE0christerholmbergericssoncom_-- From nobody Thu Jun 8 06:14:38 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F5C12EAB5 for ; Thu, 8 Jun 2017 06:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 iyX75QuuWPHr for ; Thu, 8 Jun 2017 06:14:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2232812EAD5 for ; Thu, 8 Jun 2017 06:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40129; q=dns/txt; s=iport; t=1496927668; x=1498137268; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=U9CWAiRDP1CQZnYunhFq2MTNbpsL1pnIOpnrarhuLDY=; b=gwdDOyh+0ByJPysRT/cc8d+j5PE7aBKca/CNZIwF3dqQz4CS37E69cOU 8UbNGK3+n0zOk5nzYDlPoL81f+a+0O+Ropfztx7WHet6ml4aBuSCg2BHN wOGS0wgR3+mejAM5tSP5CzXupnv0nJO4SbdEUSLnuDVGkJBklybWv7LlE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAQDNTDlZ/49dJa1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvPC1igQ2Dc4oYkUkhiCqNWIIOAyEBDIUsSgKCej8YAQIBAQE?= =?us-ascii?q?BAQEBayiFGAEBAQEDAQEhSwsQCw4DBAEBASABBgMCAiEGHwkIBg0GAgEBig8DC?= =?us-ascii?q?A0QArBagiYrhxYNhDIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZhgWArC4Jqgli?= =?us-ascii?q?BaoM6gmEFlwiGdzuHKIM3g36EX4IGhT6DSyOGT4tDiSUfOD9LUSMVR4RRORyCA?= =?us-ascii?q?SQ2igEBAQE?= X-IronPort-AV: E=Sophos;i="5.39,315,1493683200"; d="scan'208,217";a="258812818" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2017 13:14:27 +0000 Received: from [10.118.10.22] (rtp-fandreas-2-8815.cisco.com [10.118.10.22]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v58DEQLo027050; Thu, 8 Jun 2017 13:14:27 GMT To: Eric Rescorla References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> <3d52929e-a0f1-36d9-3361-93b875d355cc@cisco.com> Cc: Cullen Jennings , Christer Holmberg , "mmusic-chairs@tools.ietf.org" , RTCWeb IETF From: Flemming Andreasen Message-ID: <3f0ae431-c9cc-9912-881a-9fea23d402ca@cisco.com> Date: Thu, 8 Jun 2017 09:14:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8B8721B241FA0868B5872889" Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 13:14:32 -0000 This is a multi-part message in MIME format. --------------8B8721B241FA0868B5872889 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/7/17 10:38 PM, Eric Rescorla wrote: > > > On Wed, Jun 7, 2017 at 10:45 PM, Flemming Andreasen > > wrote: > > Based on > https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/referencedby/ > > (or you can take a look at > https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/ > ): > > draft-ietf-mmusic-dtls-sdp > > > draft-ietf-mmusic-ice-sip-sdp > > > draft-ietf-mmusic-sdp-bundle-negotiation > > > > I don't see why any of these would require ICE-bis except through trickle. > > I appreciate that the document reference graph shows a lot of > dependencies on ICE-bis, but what's not clear to me is what the > *technical* dependencies are. The MMUSIC list would be the best place to discuss that further and if you want to make changes, then I'd suggest a thread per draft to understand the technical dependencies. FYI, the MMUSIC chairs, ICE chairs and our AD (Ben Campbell) did have a discussion around this issue about a year ago in the context of bundle. At the time, we did identify references to new 5245bis behavior in the bundle draft that some people had asked for explicitly. Thanks -- Flemming > -Ekr > > > > > You will also have an issue with trickle-ice (and hence > draft-ietf-mmusic-trickle-ice-sip). > > I think that's it from an MMUSIC point of view. > > > Thanks > > -- Flemming > > > On 6/5/17 8:43 AM, Eric Rescorla wrote: >> Do you have the names of those drafts to hand? >> >> On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen >> > wrote: >> >> Please note that we have several drafts in MMUSIC that >> normatively reference 5245bis, and some of those drafts are >> RTCWeb dependencies AFAIK. >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> >> On 5/22/17 6:52 PM, Cullen Jennings wrote: >> >> Note that I don't think the timeline is the major issue >> (it is an issue) ... they key issue is that 5245bis does >> not seem to be needed for any technical reason by WebRTC. >> >> >> On May 18, 2017, at 11:03 AM, Christer Holmberg >> > > wrote: >> >> Hi, >> >> >> In general, if people have issues with referencing >> 5245bis because they are afraid it will hold up >> publication of RTCWEB specs, note that I have >> indicated to the ICE WG chairs that I think 5245bis >> is getting ready for WGLC. >> >> >> Regards, >> >> >> Christer >> >> >> From: rtcweb [mailto:rtcweb-bounces@ietf.org >> ] On Behalf Of >> Bernard Aboba >> Sent: 18 May 2017 18:50 >> To: Sean Turner > >> Cc: RTCWeb IETF > > >> Subject: Re: [rtcweb] Referring to 5245bis or 5245? >> >> >> Sean said: >> >> >> "draft-ietf-rtcweb-transports: Likewise, the chairs >> believer that a reference to RFC 5245 is also >> appropriate in transports. This draft was changed in >> version -17 to refer to 5245bis. From GH: "The >> drafts -bundle and -dualstack-fairness both depend on >> 5245bis according to Cullen's chart in >> 'rtcweb-deps-13', and we already have a normative >> dependency from -transport on these. So consistency >> of the bundle is improved by referencing 5245bis.". >> >> [BA] draft-ietf-rtcweb-overview has a normative >> reference to draft-ietf-rtcweb-transports which has a >> normative reference to >> draft-ietf-ice-dualstack-fairness which in turn has a >> normative reference to draft-ietf-ice-rfc5245bis. So >> even if you remove the normative reference to >> RFC5245bis from overview and transports, publication >> of overview will still be held up until publication >> of RFC 5245bis, which will obsolete RFC 5245. >> >> >> On Thu, May 18, 2017 at 8:37 AM, Sean Turner >> > wrote: >> >> >> On May 18, 2017, at 11:35, Sean Turner >> > wrote: >> >> >> On May 18, 2017, at 10:54, Martin Thomson >> > > wrote: >> >> I'm really confused about the statement >> regarding -transports. You >> say that 5245 is sufficient, then follow with >> justification for the >> opposite position. >> >> Sorry the change from 5425 to 5245bis was >> included in the latest version using that >> rationale. This shows to me that it was “nice” to >> get alignment and point to 5245bis not that it is >> necessary to point 5245. I.e., it’d be just fine >> to switch it back to referring to 5245. >> >> Whoops: >> >> This shows to me that it was “nice” to get alignment >> and point to 5245bis not that it is necessary to >> point 5245bis. I.e., it’d be just fine to switch it >> back to referring to 5245. >> >> >> If we have as large a dependency as bundle >> that refers to 5245bis, >> then we are taking a transitive dependency on >> 5245bis and might as >> well refer to that. >> >> A lot of this comes down to what bundle >> says. Now, I see that bundle >> depends on both 5245 and its -bis, which >> seems pretty inconsistent. I >> don't immediately see any strong reason for >> bundle to refer to the >> -bis, though it does refer to the ice-sip-sdp >> draft, which might be >> sufficiently implicated as to make the change >> necessary. We should >> ask Christer to confirm this. >> >> I think that if we clarify that either way, >> then the reference in >> -dualstack-fairness seems less of a concern; >> that document doesn't >> need to reference 5245bis, though it would be >> nice if it could. >> >> Exactly! >> >> spt >> >> On 18 May 2017 at 10:12, Sean Turner >> > wrote: >> >> ekr’s discuss on >> draft-ietf-rtcweb-overview has raised >> whether drafts should refer to RFC 5245 >> or draft-ietf-ice-rfc5245bis. We only >> need to normatively refer to 5245bis if a >> technical part of 5245bis needs to be >> read and implemented in order to >> implement the referring draft. We have 7 >> drafts that refer to RFC 5245 and 2 that >> refer to draft-ietf-rfc5245bis: >> >> draft-ietf-rtcweb-overview: As noted in >> my response to ekr’s discuss position >> [0], the chairs believe that the >> reference to “ICE” in the ICE Agent >> definition should be to RFC 5245. >> >> draft-ietf-rtcweb-transports: Likewise, >> the chairs believer that a reference to >> RFC 5245 is also appropriate in >> transports. This draft was changed in >> version -17 to refer to 5245bis. From >> GH: "The drafts -bundle and >> -dualstack-fairness both depend on >> 5245bis according to Cullen's chart in >> 'rtcweb-deps-13', and we already have a >> normative dependency from -transport on >> these. So consistency of the bundle is >> improved by referencing 5245bis." >> >> spt >> >> [0] >> https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8 >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> > > --------------8B8721B241FA0868B5872889 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 6/7/17 10:38 PM, Eric Rescorla wrote:


On Wed, Jun 7, 2017 at 10:45 PM, Flemming Andreasen <fandreas@cisco.com> wrote:

I don't see why any of these would require ICE-bis except through trickle.

I appreciate that the document reference graph shows a lot of dependencies on ICE-bis, but what's not clear to me is what the *technical* dependencies are.
The MMUSIC list would be the best place to discuss that further and if you want to make changes, then I'd suggest a thread per draft to understand the technical dependencies.

FYI, the MMUSIC chairs, ICE chairs and our AD (Ben Campbell) did have a discussion around this issue about a year ago in the context of bundle. At the time, we did identify references to new 5245bis behavior in the bundle draft that some people had asked for explicitly.

Thanks

-- Flemming



-Ekr
 



You will also have an issue with trickle-ice (and hence draft-ietf-mmusic-trickle-ice-sip).

I think that's it from an MMUSIC point of view.


Thanks

-- Flemming


On 6/5/17 8:43 AM, Eric Rescorla wrote:
Do you have the names of those drafts to hand?

On Fri, Jun 2, 2017 at 3:40 PM, Flemming Andreasen <fandreas@cisco.com> wrote:
Please note that we have several drafts in MMUSIC that normatively reference 5245bis, and some of those drafts are RTCWeb dependencies AFAIK.

Thanks

-- Flemming (as MMUSIC co-chair)


On 5/22/17 6:52 PM, Cullen Jennings wrote:
Note that I don't think the timeline is the major issue (it is an issue) ... they key issue is that 5245bis does not seem to be needed for any technical reason by WebRTC.


On May 18, 2017, at 11:03 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

 
In general, if people have issues with referencing 5245bis because they are afraid it will hold up publication of RTCWEB specs, note that I have indicated to the ICE WG chairs that I think 5245bis is getting ready for WGLC.

 
Regards,

 
Christer

 
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 18 May 2017 18:50
To: Sean Turner <sean@sn3rd.com>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Referring to 5245bis or 5245?

 
Sean said:

 
"draft-ietf-rtcweb-transports: Likewise, the chairs believer that a reference to RFC 5245 is also appropriate in transports.  This draft was changed in version -17 to refer to 5245bis.  From GH: "The drafts -bundle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a normative dependency from -transport on these.  So consistency of the bundle is improved by referencing 5245bis.".

[BA] draft-ietf-rtcweb-overview has a normative reference to draft-ietf-rtcweb-transports which has a normative reference to draft-ietf-ice-dualstack-fairness which in turn has a normative reference to draft-ietf-ice-rfc5245bis.  So even if you remove the normative reference to RFC5245bis from overview and transports, publication of overview will still be held up until publication of RFC 5245bis, which will obsolete RFC 5245.

 
On Thu, May 18, 2017 at 8:37 AM, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 11:35, Sean Turner <sean@sn3rd.com> wrote:


On May 18, 2017, at 10:54, Martin Thomson <martin.thomson@gmail.com> wrote:

I'm really confused about the statement regarding -transports.  You
say that 5245 is sufficient, then follow with justification for the
opposite position.
Sorry the change from 5425 to 5245bis was included in the latest version using that rationale.  This shows to me that it was “nice” to get alignment and point to 5245bis not that it is necessary to point 5245.  I.e., it’d be just fine to switch it back to referring to 5245.
Whoops:

This shows to me that it was “nice” to get alignment and point to 5245bis not that it is necessary to point 5245bis.  I.e., it’d be just fine to switch it back to referring to 5245.


If we have as large a dependency as bundle that refers to 5245bis,
then we are taking a transitive dependency on 5245bis and might as
well refer to that.

A lot of this comes down to what bundle says.  Now, I see that bundle
depends on both 5245 and its -bis, which seems pretty inconsistent.  I
don't immediately see any strong reason for bundle to refer to the
-bis, though it does refer to the ice-sip-sdp draft, which might be
sufficiently implicated as to make the change necessary.  We should
ask Christer to confirm this.

I think that if we clarify that either way, then the reference in
-dualstack-fairness seems less of a concern; that document doesn't
need to reference 5245bis, though it would be nice if it could.
Exactly!

spt

On 18 May 2017 at 10:12, Sean Turner <sean@sn3rd.com> wrote:
ekr’s discuss on draft-ietf-rtcweb-overview has raised whether drafts should refer to RFC 5245 or draft-ietf-ice-rfc5245bis.  We only need to normatively refer to 5245bis if a technical part of 5245bis needs to be read and implemented in order to implement the referring draft.  We have 7 drafts that refer to RFC 5245 and 2  that refer to draft-ietf-rfc5245bis:

draft-ietf-rtcweb-overview: As noted in my response to ekr’s discuss position [0], the chairs believe that the reference to “ICE” in the ICE Agent definition should be to RFC 5245.

draft-ietf-rtcweb-transports: Likewise, the chairs believer that a reference to RFC 5245 is also appropriate in transports.  This draft was changed in version -17 to refer to 5245bis.  From GH: "The drafts -bundle and -dualstack-fairness both depend on 5245bis according to Cullen's chart in 'rtcweb-deps-13', and we already have a normative dependency from -transport on these.  So consistency of the bundle is improved by referencing 5245bis."

spt

[0] https://mailarchive.ietf.org/arch/msg/rtcweb/GWdXRIO68FZwVtzzqugnELKeaY8
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

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

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




--------------8B8721B241FA0868B5872889-- From nobody Thu Jun 8 07:32:19 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7386127136 for ; Thu, 8 Jun 2017 07:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4DJ6V5-aQaO for ; Thu, 8 Jun 2017 07:32:16 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 CB097127058 for ; Thu, 8 Jun 2017 07:32:16 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m47so125442842iti.1 for ; Thu, 08 Jun 2017 07:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LkjZdBbfNN9vmZzN+a1TfpuTgCtGCKh3EbSFkGcVxB8=; b=Ick+K4JsxO7d5ALD6tRitWseil8sBRB8qkD/CcPKWEgX056cfnUrE735Kdl1sR0nQ0 2oVk7phxy4HVxU0J6FagRs4yyXRdN5VT8+GCoB7pFSKjyGcQSnj66wxWm2k9pq5+GZyN fI1jUlzDnMOii8Sub0TcP4VwSOa1UiRGSWjZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LkjZdBbfNN9vmZzN+a1TfpuTgCtGCKh3EbSFkGcVxB8=; b=PDhJ/4RUQfTPGUqPF7WfeYhtWbvWp2smkS7DNHru3obcRBeVSm0Gh7r/B3Tm/4y3cO 6Is4C9jfWnsTdQKMzJDgsEZgysjFH5tWK8pPEb6t/MZPskqPvBn/NFKhxyb1cCz6YYfD w+cFCVepXHLTA+Hp7URYVOVWQSZ8D8abKT2ClINt4GFBF+vfNGum/M1nQWY9BRqC/G6A apJOFx8HI3IvivB7X0I06vVykCC2eE7qeSv6FbdCAqBS/Hkho0mXbqDcug96tKJvQ1um 2OzbfpWSWQefjyPm+8x+uqOx/MJX0zjDhCna8RkxBUMt7SQ5v8j8QRcxdvpAamCRcSrx R5KA== X-Gm-Message-State: AODbwcDdedgz60rmjCjtH/thpR2/yzI5JpwkZWeiJcaskCFjexeM6yKg n8tRvGvenNkVhDkf X-Received: by 10.36.192.197 with SMTP id u188mr5866002itf.39.1496932336057; Thu, 08 Jun 2017 07:32:16 -0700 (PDT) Received: from ?IPv6:2001:450:1e:232:e0e2:f5a3:78ef:af82? ([2001:450:1e:232:e0e2:f5a3:78ef:af82]) by smtp.gmail.com with ESMTPSA id r77sm2338964ioe.16.2017.06.08.07.32.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 07:32:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <3f0ae431-c9cc-9912-881a-9fea23d402ca@cisco.com> Date: Thu, 8 Jun 2017 16:32:09 +0200 Cc: Eric Rescorla , "mmusic-chairs@tools.ietf.org" , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <2DD58D50-6742-4203-A7A5-BC3F037274C3@sn3rd.com> References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> <3d52929e-a0f1-36d9-3361-93b875d355cc@cisco.com> <3f0ae431-c9cc-9912-881a-9fea23d402ca@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 14:32:18 -0000 > On Jun 8, 2017, at 15:14, Flemming Andreasen = wrote: >=20 >=20 >=20 > On 6/7/17 10:38 PM, Eric Rescorla wrote: >>=20 >>=20 >> On Wed, Jun 7, 2017 at 10:45 PM, Flemming Andreasen = wrote: >> Based on = https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/referencedby/ = (or you can take a look at = https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/): >>=20 >> draft-ietf-mmusic-dtls-sdp >>=20 >> draft-ietf-mmusic-ice-sip-sdp >>=20 >> draft-ietf-mmusic-sdp-bundle-negotiation >>=20 >> I don't see why any of these would require ICE-bis except through = trickle. >>=20 >> I appreciate that the document reference graph shows a lot of = dependencies on ICE-bis, but what's not clear to me is what the = *technical* dependencies are. > The MMUSIC list would be the best place to discuss that further and if = you want to make changes, then I'd suggest a thread per draft to = understand the technical dependencies.=20 >=20 > FYI, the MMUSIC chairs, ICE chairs and our AD (Ben Campbell) did have = a discussion around this issue about a year ago in the context of = bundle. At the time, we did identify references to new 5245bis behavior = in the bundle draft that some people had asked for explicitly.=20 >=20 > Thanks=20 >=20 > -- Flemming=20 Flemming, I have to ask if those conversation happened on list? If not, it seems = to me like the shorter path might be to share those 5245bis behaviors = you identified. spt= From nobody Thu Jun 8 07:48:35 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCD3128616 for ; Thu, 8 Jun 2017 07:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 h4A9qcabRhWP for ; Thu, 8 Jun 2017 07:48:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC7C127B60 for ; Thu, 8 Jun 2017 07:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1966; q=dns/txt; s=iport; t=1496933313; x=1498142913; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=F0cZIteDYSOZBW2PgunrzKr8w5NYsxADsuurJWS/ZvE=; b=DHzXENLGfCBqizlpWwLZxg80yqS8jnZzCkpOIHxAmF/jXihi0D8az5hA TwALzZt4A4rT6QiZNv8SQqgfD8gCm/LcIEalOVdqMyGtESaJKVvGfpii9 EMNaW1LcTwPqT8ahkuFzPed4dKWnGwV0em2ay47rHqjUv1qrpHNJsX9ji E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACzYjlZ/4MNJK1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNYYoENjguRapYCghEuhXYCgno/GAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgE4QQULCxguVwYNBgIBAYoaBQgQswyMAAEBAQEBAQEBAQEBAQEBAQEBARsFh?= =?us-ascii?q?mGCC4JBNIRChhsBBJ46hyiMFIsPhnKUaB84gQpRIxVHhQocggEkNolKAQEB?= X-IronPort-AV: E=Sophos;i="5.39,315,1493683200"; d="scan'208";a="37270742" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jun 2017 14:48:32 +0000 Received: from [10.118.10.22] (rtp-fandreas-2-8815.cisco.com [10.118.10.22]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v58EmVf0009604; Thu, 8 Jun 2017 14:48:32 GMT To: Sean Turner References: <4C1F0FE7-F7E6-47F7-922D-057E4E7FA466@sn3rd.com> <3CC0A416-5A81-46FA-886C-5F43BA5193A6@sn3rd.com> <6BD64B92-4DE2-4BAD-A23D-65E8F52E13B0@sn3rd.com> <7594FB04B1934943A5C02806D1A2204B4CBA8FEF@ESESSMB109.ericsson.se> <58f45548-6c04-348b-a9e7-b87a17dbe93c@cisco.com> <3d52929e-a0f1-36d9-3361-93b875d355cc@cisco.com> <3f0ae431-c9cc-9912-881a-9fea23d402ca@cisco.com> <2DD58D50-6742-4203-A7A5-BC3F037274C3@sn3rd.com> Cc: Eric Rescorla , "mmusic-chairs@tools.ietf.org" , RTCWeb IETF From: Flemming Andreasen Message-ID: <8f33d46d-696b-cb82-cc0e-36ff76558634@cisco.com> Date: Thu, 8 Jun 2017 10:48:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2DD58D50-6742-4203-A7A5-BC3F037274C3@sn3rd.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Referring to 5245bis or 5245? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 14:48:35 -0000 On 6/8/17 10:32 AM, Sean Turner wrote: >> On Jun 8, 2017, at 15:14, Flemming Andreasen wrote: >> >> >> >> On 6/7/17 10:38 PM, Eric Rescorla wrote: >>> >>> On Wed, Jun 7, 2017 at 10:45 PM, Flemming Andreasen wrote: >>> Based on https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/referencedby/ (or you can take a look at https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/): >>> >>> draft-ietf-mmusic-dtls-sdp >>> >>> draft-ietf-mmusic-ice-sip-sdp >>> >>> draft-ietf-mmusic-sdp-bundle-negotiation >>> >>> I don't see why any of these would require ICE-bis except through trickle. >>> >>> I appreciate that the document reference graph shows a lot of dependencies on ICE-bis, but what's not clear to me is what the *technical* dependencies are. >> The MMUSIC list would be the best place to discuss that further and if you want to make changes, then I'd suggest a thread per draft to understand the technical dependencies. >> >> FYI, the MMUSIC chairs, ICE chairs and our AD (Ben Campbell) did have a discussion around this issue about a year ago in the context of bundle. At the time, we did identify references to new 5245bis behavior in the bundle draft that some people had asked for explicitly. >> >> Thanks >> >> -- Flemming > Flemming, > > I have to ask if those conversation happened on list? If not, it seems to me like the shorter path might be to share those 5245bis behaviors you identified. They were off-list. There is a reference to "ice-pwd" as part of a note that was added following list discussion. There is also a reference to ice-sip-sdp, which in turn would depend on 5245bis - there might be more (we did not do an exhaustive investigation at the time, but those two were noted). In any case, if you want to advocate changes in the MMUSIC drafts, those changes should be discussed on the MMUSIC list. Thanks -- Flemming > spt. > From nobody Tue Jun 13 01:55:14 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1075E12EBAF for ; Tue, 13 Jun 2017 01:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxJgCWuXGLGs for ; Tue, 13 Jun 2017 01:55:11 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 8A8BD12EB9E for ; Tue, 13 Jun 2017 01:55:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,337,1493676000"; d="scan'208,217";a="278576879" Received: from zmbs1.inria.fr ([128.93.142.14]) by mail2-relais-roc.national.inria.fr with ESMTP; 13 Jun 2017 10:55:00 +0200 Date: Tue, 13 Jun 2017 10:55:00 +0200 (CEST) From: Kevin Corre To: rtcweb@ietf.org Message-ID: <732275704.86150599.1497344100559.JavaMail.zimbra@inria.fr> In-Reply-To: <779528943.86140527.1497343604808.JavaMail.zimbra@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_86150598_50258425.1497344100558" X-Originating-IP: [131.254.67.174] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF53 (Mac)/8.0.9_GA_6191) Thread-Topic: ICWE short paper on WebRTC IdP Proxy implementation Thread-Index: lq0Zy21e9xVmM87si1yhC1tGQS5tFA== Archived-At: Subject: [rtcweb] ICWE short paper on WebRTC IdP Proxy implementation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 08:55:13 -0000 ------=_Part_86150598_50258425.1497344100558 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, We just presented a short paper to the ICWE'17 conference in which we describe our implementation of WebRTC IdP Proxy with OIDC servers. We also implemented identity negotiation in WebRTC and we describe what worked and what did not. I thought it might interest peoples on the list. If you have time to read it, I would gladly hear feedback and remarks. The paper is available at : https://link.springer.com/chapter/10.1007/978-3-319-60131-1_27 (or on my website if you don't have springer access, kcorre.github.io). Regards, Kevin ------=_Part_86150598_50258425.1497344100558 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We just presented a short paper to the ICWE'17 conference in which we= describe our implementation of WebRTC IdP Proxy with OIDC servers.
We= also implemented identity negotiation in WebRTC and we describe what worke= d and what did not.

I thought it might intere= st peoples on the list. If you have time to read it, I would gladly hear fe= edback and remarks.

The paper is available at= : https://link.springer.com/chapter/10.1007/978-3-319-60131-1_27 (or o= n my website if you don't have springer access, kcorre.github.io).

Regards,
Kevin

=
------=_Part_86150598_50258425.1497344100558-- From nobody Tue Jun 13 09:23:49 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADF5131A1E for ; Tue, 13 Jun 2017 09:23:47 -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 p5jQeUksspiE for ; Tue, 13 Jun 2017 09:23:46 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 602D1131958 for ; Tue, 13 Jun 2017 09:17:08 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id w1so177762199qtg.2 for ; Tue, 13 Jun 2017 09:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NKVYP+FFfIWIyKfYlIe8xzDG2xaxoMNRudY5BkjSdgY=; b=Dhcd+gS+NWfgz3wFGJ1sQqbRmQpumTVX2XHm5P1fD9OnjuoCk6SMjLL8YiEZ6tbHmn pebSYJhqsJq1HXQt4dMLJMoFjvj0+avgscy96T3DEt3mu7jKkWrRpBluwW0KFvOMnm7r 1UoN5dazgbOsgYLU3rmbYKXLq9/fvaqckLv5zJMVaE9RIxj9+fJGN+xiVYgOPSLBSsjC BEzk7bqKpYcqAysWRSafrWuDzZvNdCjnSHPu31/VUhu/jsiJvMggYcQ1rXb3kTSDGYV5 H79pJp4sNFgL7gdFPHHT7VSCdz6OSU5prRSsWctUO7Rp3YxAU69q8ZU8f9v0zTVTYIYl LrkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NKVYP+FFfIWIyKfYlIe8xzDG2xaxoMNRudY5BkjSdgY=; b=lzny780GNmqU1wm/tX9jOTlzTBpM33BaENiTdEW07A2i4JEetm7sasNeIkSnwQHTpS D1rQWmh0lwa3H5bNugWS3hxHwNR+rmYlru/o4KcvmKthO6UV5VnaOHJlqhBZllsKbL6k OReFCl3IzDL8FmJKjYXyhcs7ZS1+xMDXDybHC5XyqbMFMBLFV7KrTC+0AmA3ku0k30HV EE74eOsrzMF/T7LQlNU4F/+cv91YG+Q4s8arxovtEkbFqR/+YnoBroyV9DSprpXspi5w h0zAfP5VAwvd7GIUqBjGVy2x7PFKqmNp8bLVledTM+DwRPiMJuGlTqJr2zpQ73MJmNLE fUnw== X-Gm-Message-State: AKS2vOyCHs9gSIbqpIh6JSSocfWuyGVr/kYxHS4JL7jd1TRD6vByZCkv NO1S0IdtCIuXA5Pm0mVk4KyWAkybxg== X-Received: by 10.55.71.205 with SMTP id u196mr883377qka.7.1497370627352; Tue, 13 Jun 2017 09:17:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.34.9 with HTTP; Tue, 13 Jun 2017 09:16:37 -0700 (PDT) In-Reply-To: <732275704.86150599.1497344100559.JavaMail.zimbra@inria.fr> References: <779528943.86140527.1497343604808.JavaMail.zimbra@inria.fr> <732275704.86150599.1497344100559.JavaMail.zimbra@inria.fr> From: Ted Hardie Date: Tue, 13 Jun 2017 09:16:37 -0700 Message-ID: To: Kevin Corre Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="001a114a90ac5730500551d9c4c9" Archived-At: Subject: Re: [rtcweb] ICWE short paper on WebRTC IdP Proxy implementation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 16:23:48 -0000 --001a114a90ac5730500551d9c4c9 Content-Type: text/plain; charset="UTF-8" Thanks very much for the pointer. As someone who recently implemented the specifications, any comments you have on the security documents would be very welcome. Though expired, we are hoping to have them refreshed and sent through the rest of the process soon, so the comments would be timely as well. best regards, Ted Hardie On Tue, Jun 13, 2017 at 1:55 AM, Kevin Corre wrote: > Hi, > > We just presented a short paper to the ICWE'17 conference in which we > describe our implementation of WebRTC IdP Proxy with OIDC servers. > We also implemented identity negotiation in WebRTC and we describe what > worked and what did not. > > I thought it might interest peoples on the list. If you have time to read > it, I would gladly hear feedback and remarks. > > The paper is available at : https://link.springer.com/ > chapter/10.1007/978-3-319-60131-1_27 (or on my website if you don't have > springer access, kcorre.github.io). > > Regards, > Kevin > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a114a90ac5730500551d9c4c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks very much for the pointer.=C2=A0 As someo= ne who recently implemented the specifications, any comments you have on th= e security documents would be very welcome.=C2=A0 Though expired, we are ho= ping to have them refreshed and sent through the rest of the process soon, = so the comments would be timely as well.

best regards,

=
Ted Hardie

On Tue, Jun 13, 2017 at 1:55 AM, Kevin Corre <= ;kevin.corre@inri= a.fr> wrote:
Hi,

We just presented a sho= rt paper to the ICWE'17 conference in which we describe our implementat= ion of WebRTC IdP Proxy with OIDC servers.
We also implemented identit= y negotiation in WebRTC and we describe what worked and what did not.
<= /div>

I thought it might interest peoples on the list. I= f you have time to read it, I would gladly hear feedback and remarks.
<= /div>

The paper is available at : http= s://link.springer.com/chapter/10.1007/978-3-319-60131-1_27 (o= r on my website if you don't have springer access, kcorre.github.io).
Regards,
Kevin


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

--001a114a90ac5730500551d9c4c9-- From nobody Sat Jun 17 18:57:34 2017 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F359120454 for ; Sat, 17 Jun 2017 18:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOLTullrawYH for ; Sat, 17 Jun 2017 18:57:30 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EDE1201F2 for ; Sat, 17 Jun 2017 18:57:30 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id g66so37599174vki.1 for ; Sat, 17 Jun 2017 18:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=egUst2U6HKgztfW1qQ+McsxC38wdksSkVdAx57QTx8E=; b=RMzsheFZyoHJ5HS7WqCA9dKdkyqXlY32APIkGzmukdieKl2ZvtAl2BeCQ1T7ENwy8i AgJQl07w51ojlN5sVqSBBIuSIBPlxVR3dbuYseHxW3OENRBCwLx8zWFNC76sPTo6NQoN EpXAYZMTgdVCdHgSvhCoCSpaM0cfmKRcAG4RqLUBDcxPgmUCMb8H2+W1twQtJ8vnmTVe ALZaxCuPBXtmtGL/bnjPkpzCYqItv7+GC1Cw+Wm7jWBfmDENCGICKd4eZoKgJeZ7uTn0 QGCCxErfSMLgJvV0tCurZ9/9p0ntTu3vr5dgwhoq/ZMztrVYhYW6ZbQrj6t8AcChEwa8 hpJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=egUst2U6HKgztfW1qQ+McsxC38wdksSkVdAx57QTx8E=; b=OWNOm07VxJPoIKhqb9f5GyD037l6x5gae+aaGuGAXELqmD4q+rTNruMsuv8YVXIua/ p2bybJjylGYrIdwUKNhM2F7PzX5AXoCNApM28pL1l0SyGK8ATckp8n00n3tj65++cts8 E7t6C/d1q8G1lIUdnmUeHEGrR3LYcRw6+iFjWPnhYtvzIJTRnqO479LNhu5D7Ne962u/ nKDxiwlFo1jLcEZx6/sjPZlUQ+X6K1fxy8gL7rgbSqxv1KgmHuLj4ZF/A8FrFHnACNnN 5PNSFK4BdDSSZqVoa3Rbzp8/foN8vFc4cJ3VCIu0GcZM89eg1zpn8+/Hkb/E9L33r/IP avRg== X-Gm-Message-State: AKS2vOwnr1AHO/ifxWxoIEk3UvfOPTjWcdMHjk/SeD96njtqjhR4gaDW s877KU7EBTlFn6rmBSQhEyEK+40aQM1CHCE= X-Received: by 10.31.173.134 with SMTP id w128mr9705893vke.125.1497751049371; Sat, 17 Jun 2017 18:57:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.52.218 with HTTP; Sat, 17 Jun 2017 18:57:09 -0700 (PDT) From: Bernard Aboba Date: Sat, 17 Jun 2017 18:57:09 -0700 Message-ID: To: "rtcweb@ietf.org" Cc: "fluffy@cisco.com" , =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary="001a1143f0ce4286a40552325708" Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-security-arch Section 5.5: mandatory-to-implement certificate algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 01:57:33 -0000 --001a1143f0ce4286a40552325708 Content-Type: text/plain; charset="UTF-8" Currently, draft-ietf-rtcweb-security-arch Section 5.5 specifies mandatory-to-implement (D)TLS ciphersuites. However, it does not specify the mandatory-to-implement certificate algorithms. Issue https://github.com/w3c/webrtc-pc/issues/1258 has been filed against the WebRTC 1.0 specification Section 4.10, which states: The following values must be supported by a user agent : { name: "RSASSA-PKCS1-v1_5 ", modulusLength: 2048, publicExponent: new Uint8Array([1, 0, 1]), hash: "SHA-256" }, and { name: "ECDSA ", namedCurve: "P-256 " }. NOTE It is expected that a user agent will have a small or even fixed set of values that it will accept. Can this text (or some suitable replacement) be added to draft-ietf-rtcweb-security-arch? Bernard Aboba On behalf of the W3C WEBRTC WG --001a1143f0ce4286a40552325708 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently, draft-ietf-rtcweb-security-arch Section 5.5 spe= cifies mandatory-to-implement (D)TLS ciphersuites.=C2=A0 However, it does n= ot specify the mandatory-to-implement certificate algorithms.=C2=A0
Issue=C2=A0https://github.com/w3c/webrtc-pc/issues/1258 has been filed a= gainst the WebRTC 1.0 specification Section 4.10, which states:=C2=A0

The following values=C2=A0must=C2=A0be supported by a=C2=A0user agent:=C2=A0{ name: "RSASSA-PKCS1-v1_5", modulusLength: 2048, public= Exponent: new Uint8Array([1, 0, 1]), hash: "SHA-256" }, an= d=C2=A0{ name: "ECDSA", namedCurve: "P-256" }.

N= OTE

It is expected th= at a=C2=A0user agent=C2=A0will have a small or even fixed set of values that= it will accept.


Can this text (or some = suitable replacement) be added to draft-ietf-rtcweb-security-arch?

Bernard Aboba
On behalf of the W3C WEBRTC WG
--001a1143f0ce4286a40552325708-- From nobody Fri Jun 23 17:12:29 2017 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2F12EB11; Fri, 23 Jun 2017 17:07:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: adam@nostrum.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282985.7840.9489372505743073542.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:09 -0700 Archived-At: Subject: [rtcweb] rtcweb - Requested session has been scheduled for IETF 99 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:10 -0000 Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rtcweb Session 1 (2:00:00) Monday, Afternoon Session I 1330-1530 Room Name: Congress Hall I size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: perc sipcore payload mmusic acme stir httpbis dispatch clue avtext avtcore aqm rmcat tls quic Second Priority: dprive tcpinc tsvwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen opsawg People who must be present: Eric Rescorla Sean Turner Adam Roach Cullen Jennings Martin Thomson Alissa Cooper Ted Hardie Justin Uberti Harald Alvestrand Resources Requested: Special Requests: ---------------------------------------------------------