Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12

Harald Alvestrand <harald@alvestrand.no> Tue, 17 October 2017 19:32 UTC

Return-Path: <harald@alvestrand.no>
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 AAD96132D4E; Tue, 17 Oct 2017 12:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 FXcjM5mEkJri; Tue, 17 Oct 2017 12:32:23 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B609F13292A; Tue, 17 Oct 2017 12:32:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 330007C32DB; Tue, 17 Oct 2017 21:32:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcjE5-Gq14v3; Tue, 17 Oct 2017 21:32:20 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 443C17C0AF4; Tue, 17 Oct 2017 21:32:20 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <66220024-e08b-aa61-ffe2-3c279c377a34@alvestrand.no> <D60A5C84.23E43%christer.holmberg@ericsson.com> <f4da1671-f7bd-e153-04da-a0462316798d@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B5635D4B5@ESESSMB109.ericsson.se>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <1cb09b36-54db-afc1-ff5f-4a37c1701a23@alvestrand.no>
Date: Tue, 17 Oct 2017 21:32:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5635D4B5@ESESSMB109.ericsson.se>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/qRG02SrCzz2TkFmsarm-s5es8m0>
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 17 Oct 2017 19:32:24 -0000

Leaving in only the one with something left to write...

Den 17. okt. 2017 21:26, skrev Christer Holmberg:
>> I was thinking of something like:
>>
>> The exchange of information MUST result in the following information being available to the ICE agent:
>>
>> - Whether the remote peer supports ICE at all
>> - What ICE options, if any, are supported
>> - Whether the remote peer is Lite or Full
>> - Whether the remote peer thinks it's the Initiating Agent or not
>> - What candidates the remote peer wishes to make available
>> - Whether an ICE restart is desired
> Looks ok, but I am not sure what mean by the 4th, regarding thinking it's the initiating agent or not.
> 
> 

The spec says that the initiating agent will take the CONTROLLING role
if both parties are Full ICE implementations, or if both parties are
Lite implementations. This means that it has to know that it's the
initiating agent.

In cases like Offer/Answer (without glare), it's simple to see which one
is initiating. In cases with 3rd party control (both parties get called
for setup), chat-line systems (both parties initiate a join) or
protocols where glare is possible, something has to make the decision on
which side has the Initiator role.

I'd prefer to abandon the Initiator concept, and say that the exchange
of information should give back the information to each about whether
they should try to take the Controlling role, but that may be a larger
rewrite.