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

Adam Roach <adam@nostrum.com> Fri, 07 September 2018 00:54 UTC

Return-Path: <adam@nostrum.com>
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 DC14E130FE6; Thu, 6 Sep 2018 17:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=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 1IFrF4JP06-g; Thu, 6 Sep 2018 17:54:16 -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 AB68212F295; Thu, 6 Sep 2018 17:54:16 -0700 (PDT)
Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w870sDod037951 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Sep 2018 19:54:15 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at
To: Cullen Jennings <fluffy@iii.ca>, Applications and Real-Time Area Discussion <art@ietf.org>
Cc: RTCWeb IETF <rtcweb@ietf.org>, "clue@ietf.org" <clue@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "ice@ietf.org" <ice@ietf.org>
References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca>
From: Adam Roach <adam@nostrum.com>
Message-ID: <f9404aeb-ea43-3f29-d668-fd7095016caf@nostrum.com>
Date: Thu, 6 Sep 2018 19:54:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/MZcVLnWIGVhuuJYl2fABJ77KEYA>
Subject: Re: [rtcweb] [art] [clue] ICE, ICE-bis, and Cluster 238
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 07 Sep 2018 00:54:24 -0000

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.

https://trac.ietf.org/trac/art/wiki/c238

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