Re: Call for Consensus: ICE Transport Extensions for WebRTC

Thanks for the document review!

This call for consensus is to confirm the previous percieved consensus
to adopt this document; if we're going to be able to instantiate
transports without using the PeerConnection API, they have to be
instantiated using an ICE transport or something similar, so this seems
like an useful building block, no matter which transports we decide to
run on top of it.

I do agree that referencing QUIC (except possibly as an example of a
potential client for this spec) shouldn't be needed.

On 04/17/2018 09:01 PM, Lennart Grahl wrote:
> Hi,
>
> I don't understand (yet) where this is going. With this extension, one
> can create an RTCIceTransport instance... which is standalone and not
> associated to an RTCPeerConnection. So, there is nothing one can do with
> it since the extension doesn't specify any kind of interaction between
> itself and RTCPeerConnection.
>
> Regarding the spec itself, a few questions and notes:
>
> * The methods reference `state` but it's not an attribute or references
> an internal slot.
> * What happens if .gather() is being called again, possibly even after
> .start() has been called?
> * The .start() method:
>   - What happens if .gather() hasn't been called, yet?
>   - It refers to a `gatherer` argument in step 6 which doesn't exist (I
> assume this is from the ORTC spec).
>   - Why does `RTCIceRole` default to `controlled`?
> * Missing definition of `RTCIceCandidateComplete` in
> .addRemoteCandidate(...).
> * How is an `RTCIceCandidate` instance being created before passing it
> as an argument to .addRemoteCandidate(...)? In ORTC it's defined as a
> dictionary but in WebRTC it's not. And I'm not aware of ways to create
> an instance without `RTCIceCandidateInit` which requires SDP.
> * 5.1 Impact on same origin policy: Shouldn't that mention that mode 2
> will be used by default in case no consent (in whatever form) has been
> provided? Also, not really sure why it refers to a "QUIC API" here.
> * 5.2 Impact on local network: I'm unaware ICE encrypts anything. And it
> also mentions using congestion control (also refers to QUIC for some
> reason). Pretty sure that doesn't apply to ICE.
> * 5.3 Confidentiality of Communications: Seems to be moot for an ICE
> transport.
> * There should be an example
> (https://w3c.github.io/webrtc-ice/#examples*). :)
>
> Cheers
> Lennart
>
>
> On 17.04.2018 19:45, Bernard Aboba wrote:
>> This is a call for consensus on the Editor's Draft "ICE Transport Extensions for WebRTC", which is being considered for acceptance as a WG document. 
>>
>> The document is available for inspection here: 
>> https://w3c.github.io/webrtc-ice/
>>
>> Abstract
>> This document defines a set of ECMAScript APIs in WebIDL to allow construction of an RTCIceTransport interface in situations where such an interface would not be created in the WebRTC 1.0 API (such as when data is exchanged using QUIC). This specification is being developed in conjunction with protocol specifications developed by the IETF ICE Working Group.
>>
>> Please respond to this email with your review (and opinions on whether it is ready for acceptance as a WG document) by May 4, 2018. 
>>

-- 
Surveillance is pervasive. Go Dark.

Received on Tuesday, 17 April 2018 21:20:25 UTC