Re: [rtcweb] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238

Cullen Jennings <> Fri, 07 September 2018 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8462D12F1A2 for <>; Fri, 7 Sep 2018 09:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 25gVUBCeG424 for <>; Fri, 7 Sep 2018 09:24:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B67FE130E02 for <>; Fri, 7 Sep 2018 09:24:43 -0700 (PDT)
Received: from (localhost []) by (SMTP Server) with ESMTP id AFAD660097; Fri, 7 Sep 2018 12:24:42 -0400 (EDT)
Received: by (Authenticated sender: with ESMTPSA id 182B46007D; Fri, 7 Sep 2018 12:24:42 -0400 (EDT)
Received: from [] ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.7.12); Fri, 07 Sep 2018 12:24:42 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Cullen Jennings <>
In-Reply-To: <>
Date: Fri, 7 Sep 2018 10:24:40 -0600
Cc: Applications and Real-Time Area Discussion <>, "" <>, RTCWeb IETF <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Adam Roach <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [rtcweb] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Sep 2018 16:24:47 -0000

That’s a very useful graph but when I look at the what is actually used in the purple links, most of them seem they could trivial work with any version of ICE with the exception of the few places trickle is used and need the explicit stuff around how to deal with trickle. 

> On Sep 6, 2018, at 6:54 PM, Adam Roach <> wrote:
> On 9/6/18 3:24 PM, Cullen Jennings wrote:
>> I would propose that instead of the parts of specs that use the trickle mechanism purely reference that part of the new ICE spec that defines the syntax and say to transfer trickle candidates.
> Unfortunately, it's not quite so simple. The mismatch with trickle-ice is only the most obvious problem. In practice, there are a few dozen places where unpublished documents in the cluster refer directly to one version of ICE, and indirectly to another, or indirectly to both.
> To help wrap our collective minds around this issue, I've put together a dependency graph that shows which Cluster 238 documents refer to which version of ICE. The red lines indicate references (directly or indirectly) to RFC 5245, while the purple lines indicate references to RFC 8445. The thickness of the line indicates how many hops away from ICE the reference is. Dotted lines are informative references.
> To put a finer point on this, it took me a couple of hours to pare this graph down to something that was small enough to look at and actually understand -- there are actually twice as many documents involved in this mess, but including them makes the situation too confusing to even start to get a grip on.
> Everywhere you see a purple document with a red arrow or vice-versa is a place we need to figure out how to handle this mismatch. You can push the boundaries around, but the count of mismatches is pretty much the same no matter how you do that. On a first order estimation, this is days -- or, more likely, weeks of work. And I'm talking about person-hours, not calendar time. If you can do this, or find someone to step up and do it, then your proposal would be a viable alternative to the one that the ART ADs have proposed. Short of that, I'm not sure how we can do what you want.
> /a
> _______________________________________________
> mmusic mailing list