[rtcweb] ICE, ICE-bis, and Cluster 238

Adam Roach <adam@nostrum.com> Wed, 22 August 2018 17:59 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C2597130DBE; Wed, 22 Aug 2018 10:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mx8eKgY6Uw9Q; Wed, 22 Aug 2018 10:59:08 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338B1130E01; Wed, 22 Aug 2018 10:59:08 -0700 (PDT)
Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net []) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7MHwxF3079673 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Aug 2018 12:59:01 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [] claimed to be Svantevit.roach.at
From: Adam Roach <adam@nostrum.com>
To: Applications and Real-Time Area Discussion <art@ietf.org>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "clue@ietf.org" <clue@ietf.org>
Reply-To: Applications and Real-Time Area Discussion <art@ietf.org>
Message-ID: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com>
Date: Wed, 22 Aug 2018 12:58:50 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------25F6808114B810D3242F1D07"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/AELiBgVGYF3CwaUY06JGW_318_Q>
Subject: [rtcweb] ICE, ICE-bis, and Cluster 238
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Aug 2018 17:59:12 -0000

Members of the ART community interested in real-time communications:

Cluster 238 [1] is a set of inter-related documents dealing with 
real-time communications. The bulk of these documents relate to WebRTC, 
either directly or indirectly. They also form the underpinnings of CLUE. 
As of now, there are 34 documents in the cluster that are not yet 
published, with 25 of these already in the RFC Editor's queue. The 
dependency graph among these documents is such that the bulk of them can 
be published as soon as a specific six of them are handed off to the RFC 
editor, and we expect this to happen in the upcoming few months.

One long-running complication for this cluster of documents is that each 
of the documents were developed over the course of seven years, in 
concert with implementations, while the ICE protocol itself was 
undergoing significant revision. As a consequence, some documents rely 
(directly or indirectly) on the older ICE specification (RFC 5245), 
while some rely on the newer one (RFC 8445). In some cases, documents 
refer directly to the old version and transitively to the new version.

It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the 
mechanism described in RFC 8445 has someĀ  changes that break backwards 
compatibility with the mechanism defined in RFC 5245 (with such 
behavioral changes controlled by an SDP attribute, allowing clients to 
transition from one to the other).

Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol 
in the IETF) refers to directly to RFC 5245, while relying on the 
behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in 
turn, is based on the newer RFC 8445 handling. JSEP's reference to RFC 
5245 is a practical consideration that acknowledges that current 
deployments of WebRTC implement the older version of ICE. At the same 
time, these deployed implementations use a somewhat older version of 
draft-ietf-ice-trickle in concert with the older ICE implementation.

In order to get Cluster 238 published, we need to find some way to 
rationalize its references to ICE. At a basic level, the ART Area 
Directors do not believe that it makes sense to publish new documents 
that refer to an already obsoleted RFC. At the same time, we recognize 
that there is value in our specifications being informed by running 
code. For WebRTC, the complexity of the system has led us to a point 
that we must choose between these principles. Our proposal is to choose 
the first, while acknowledging the second.

This would result in a request to the RFC editor to update all 
references to RFC 5245 in the Cluster 238 documents to instead point to 
RFC 8445. Documents not yet in the RFC editor queue would be updated 
prior to IESG review. We would further request that the RFC editor add 
the following text to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep:

> While this specification formally relies on [RFC8445], at the time of 
> its publication, the majority of WebRTC implementations support the 
> version of ICE described in [RFC5245], and use a pre-standard version 
> of the trickle ice mechanism described in [RFCXXXX]. The use of the 
> "ice2" attribute defined in [RFC8445] can be used to detect the 
> version in use by a remote endpoint and to provide a smooth transition 
> from the older specification to the newer one. 
RFC 8445 would be a normative reference for both documents, while RFC 
5245 would be informative.

There is one more minor complication, in that 
draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 
5245) is intended to be an exhaustive list of the SDP attributes defined 
in the documents it lists, and RFC 8445 adds a new "ice2" attribute that 
was not present in RFC 5245. For this reason, we would also ask the RFC 
Editor to add a new row to the table in 
draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows:

>     +-------------------+---------------------------+-------+-----------+
>     | Name              | Notes                     | Level | Mux       |
>     |                   |                           |       | Category  |
>     +-------------------+---------------------------+-------+-----------+
>     | ice2              | Not Impacted              | S     | NORMAL    |
>     |                   |                           |       |           |
>     +-------------------+---------------------------+-------+-----------+

For clarity, the affected documents are as follows.

The following documents would be updated to reference RFC 8445 prior to 
IESG evaluation:

  * draft-ietf-clue-datachannel
  * draft-ietf-clue-signaling
  * draft-ietf-rtcweb-security
  * draft-ietf-rtcweb-security-arch

The following documents would be updated to reference RFC 8445 by the 
RFC Editor:

  * draft-ietf-mmusic-mux-exclusive
  * draft-ietf-mmusic-sctp-sdp
  * draft-ietf-rtcweb-alpn
  * draft-ietf-rtcweb-data-channel
  * draft-ietf-rtcweb-rtp-usage

The following documents would be updated to reference RFC 8445 and have 
the text proposed above added to them:

  * draft-ietf-rtcweb-jsep
  * draft-ietf-rtcweb-overview

The following document would be updated to reference RFC 8445 by the RFC 
Editor, and include a new row for "ice2" in its Section 5.12, as 
described above:

  * draft-ietf-mmusic-sdp-mux-attributes

This message is cross-posted to the affected working groups. Because the 
issue at hand has impact across several different groups, we ask that 
all follow-up discussion take place on <art@ietf.org>;. Thank you.

/Adam on behalf of the ART Area Directors

[1] https://www.rfc-editor.org/cluster_info.php?cid=C238