Filling in relative information from @martinthomson's post in the original TAG review:

Background

These two specifications are very different, and should probably be the subject of separate analyses, but it is convenient that they appear together. I'll get back to QUIC later, but I want to first look at ICE.

The WebRTC WG has, for a number of years, been dedicated to establishing peer-to-peer communications. ICE is a fundamental part of that. ICE exists primarily to facilitate connection establishment in challenging network conditions (NATs, etc...). It does this by testing all possible communication paths, looking for the best one that works. The part that I want to focus on here is its function in providing confirmation of a willingness to communicate. As part of the testing process, ICE also confirms that the entity at the other end understands the communication and consents to it continuing.

For classic WebRTC uses cases, ICE exists primarily as a defense against denial of service: you don't want to be responsible for sending a fat stream of video to someone who doesn't want it. This is what ensures that web browsers can't be turned into a DoS platform.

The ICE transport spec represents an effort by the WebRTC community to provide lower-level tools for web developers. This is complementary to other efforts to decompose the giant ball of wax that is WebRTC into reusable components.

Consent to Communicate on the Web

We most often think of consent to communicate in the context of CORS. User agents use CORS to confirm that the server understands and is willing to continue communication. Though we let some requests through for legacy reasons, we first confirm (with a preflight request) that the server consents to receiving the request.

Some of the more onerous and awkward provisions in CORS derive from it being retrofitted to the web. The web for a long time didn't have programmatic access to HTTP requests, and a number of servers were deployed that were not prepared for that access. This was worst in cases where servers made the (bad) assumption that access to the network was sufficient for authorization. If browsers allowed random sites to generate requests toward those internal servers without checking first, bad things would happen.

The parallels between ICE and CORS is something that earlier versions of WebRTC didn't really concern themselves with. WebRTC 1.0 is a relatively high-level API that provides the ability to exchange media and data between peers. In that narrow context, limiting the consent function of ICE to simple denial-of-service protection makes sense.

ICE and Raw Socket Access

If we look at ICE as a more fundamental building block, we end up with new possibilities. We've struggled in the past with APIs that enabled raw socket access (such as the TCP and UDP socket API). ICE presents an option that would enable those uses.

The primary concern with those previous attempts is in exposing a capability to the web platform that enables communications with arbitrary, unprepared hosts. The scope of problems with CORS would be a pale shadow of the problems with services that operate at the next layer down in the stack.

ICE provides a way of verifying that a peer is willing to communicate. That suggests that it might be used to enable communication for more than just WebRTC. Sure, you aren't going to enable access to existing services without first teaching them how to indicate their consent to communicate, but that's the feature we needed. The consent parts of ICE are fairly simple, and deploying them could allow new services to become web-accessible.

The RTCIceTransport spec makes no effort to address these possibilities. It says nothing about how it might be used, which leaves the field fairly open. It probably assumes the narrow set of existing peer-to-peer use cases. Given that this could enable much more, some consideration of its broader applicability is wise. For instance, though it might enable DNS to UDP port 53, I would argue that it shouldn't on the basis that we should not be enabling the creation of unencrypted and unauthenticated communications channels from the web.

Hi! Thanks for making us aware of this. I've noticed that the explainer seems to have restricted access - could you possibly open up the access restrictions? Same applies for both explainers.

The access for the explainer seems OK now.

Thank you for bringing this to our attention.

This is still a on-going discussion within the group, but the last call's minutes are here - and related feedback has also been provided here.

Apologies for this feedback being a bit delayed.

One question: the explainer asserts that RTCIceTransport isn't useful by itself. Is that because it essentially has an "internal" API that can be used by things like RTCQuicTransport but that isn't exposed to javascript users via the spec'd interface? Is that, in turn, justified by what @martinthomson writes above: "we should not be enabling the creation of unencrypted and unauthenticated communications channels from the web"? (At this point I'm at an inference on top of an inference, so I've probably gone wrong somewhere!)

On a side note, I'd note that the naming violates the casing section of the design principles doc, which says (although maybe it should be revised?):

Repeated initialisms are particularly non-uniform throughout the platform. Infamous historical examples that violate the above rules are XMLHttpRequest and HTMLHtmlElement. Do not follow their example; instead always capitalize your initialisms, even if they are repeated.

We discussed this at our TAG face-to-face in Paris, and were joined by @martinthomson. (Thanks Martin!) On behalf of his IETF working group, he has requested some time to finish off the work they've been doing.

We concluded that we will not push a joint conversation with the WebRTC folks right now. In the meantime, we will carry on with the review and our discussions about making the stack less WebRTC-specific.

To be clear, the working group is not mine. I'm just relaying comments already made by the chairs in other places. My assessment is that we're really close to finalizing the design and that policy might change relatively soon, but I'll defer to Lars and Mark on how they want to manage that.

Ping - is this TAG review going forward, and on what timeline? Note about the naming issue: This class was named in the WebRTC specification and is widely implemented; the current specification is an extension of that API. So changing the name of the class would impact existing implementations.

https://github.com/w3ctag/design-reviews/issues/303#issuecomment-495167918

@dbaron and I discussed this in a breakout today, and ended up admitting that we don't understand enough to provide a meaningful review. I'm taking an action to pick some brains (the publicly available documentation and spec didn't make understanding this easier) to understand the implementation details a bit more before we attempt to review this.

We're really sorry about this, I think we've spent too much time on this without making much progress due to a lack of expertise. For these reasons, we would like to close this off. Apologies.