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

I suggest to add the following text to section 2.8 (Usages of ICE):

Each usage of ICE MUST define mechanisms for the ICE agents to exchange the following information:
-	Whether the ICE agents supports ICE.</t>
-	What ICE options, if any, the ICE agents support.</t>
-	Whether an agent represents a Lite or Full ICE implementation.</t>
-	Whether an agent assumes it is has the role of the Initiating Agent.</t>
-	The ICE candidates that the ICE agent wants to make available.</t>
-	Whether the ICE agent want to trigger an ICE restart.</t>

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 19 October 2017 17:30
To: Harald Alvestrand <harald@alvestrand.no>; ice@ietf.org
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12 - Information exchange requirements

Hi Harald (and others),

Do you think we should add a new section ("ICE using protocol requirements", or something), or do you think the text fits in an existing section?

Section 4.3 already contains some requirements regarding candidate exchange (the 5th bullet in your list), but I don't think the other requirements fit there.

Regards,

Christer

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.

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