4) [rfced] Adam Roach previously requested that "All other

[juberti]

4) [rfced] Adam Roach previously requested that "All other documents in Cluster 238 that currently reference RFC 5245 should be updated to reference RFC 8445. ... any other references to RFC 5245 that I may have overlooked should also be updated."

We believe this document intentionally refers to both RFCs. Please let us know if any updates are needed.

[juberti]

I reviewed this and it seems correct, although S 5.1.1 is a bit confusing when it says that ICE, as specified in [RFC8445], MUST be used., even though we explicitly allow 5245-ICE in S 3.5.5.

@fluffy, thoughts on this?

[juberti]

I think that what we probably want here is something like:

ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use
 an older version of ICE or ICE Lite; implementations MUST properly handle remote 
endpoints who use ICE or ICE Lite as specified in RFC5245.

@fluffy, any further thoughts? Planning to mark this as editor-ready.

[juberti]

@adamroach in case he has thoughts on this

[fluffy]

Get me back up to speed on all this ... My recollection is this 1) this was widely discussed in th WG and adam was on one end of the fence. 2) the connection performance and RFC8445 is worse than RFC5245 and thus Cisco does not plan to move to RFC8445 until there is a new version that brings it back to 5245 performance. We want it to be OK to use either and specifically we do not want JSEP to require 8445. This is a major and significant change and certainly not something the AD should do in auth48. Is that about right

[adamroach]

This is a major and significant change and certainly not something the AD should do in auth48.

Just for clarity, this wasn't a unilateral AUTH48 change. The current state of ICE support in the documents is the result of a 55-message, 8-week consultation with the community in the late summer/early fall of 2018.

I'd really rather not re-litigate this; but, if that's what needs to happen, then it's a matter of getting @mskucherawy or Barry to bring it back to the ART community again rather than the few of us working through it in github (which would be a very opaque and cliquish way to handle things).

The proposal that had broad buy-in from the community [1] was around the specific text:

While this specification formally relies on [RFC8445], at the time of 
its publication, the majority of WebRTC implementations support the 
version of ICE described in [RFC5245], and use a pre-standard version 
of the trickle ice mechanism described in [RFCXXXX]. The use of the 
"ice2" attribute defined in [RFC8445] can be used to detect the 
version in use by a remote endpoint and to provide a smooth transition 
from the older specification to the newer one. 

Accompanied by the specific note that "RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative." So, to the crux of this ticket: yes, JSEP would reference both. 8445 normatively, and 5285 informatively.

If the contents of this document vary substantively from that community-vetted text I cite above, then you'd definitely need sign-off by the current ART ADs. (Tagging @ajeanmahoney on this statement for her awareness.)

---

[1] There were several voices of support, with only two objectors: John Klensin on procedural grounds, and Cullen on both procedural grounds and content. I consider Cullen's procedural objections cured by subsequent accomodations, and John's as being general in nature rather than bearing directly on the disposition of this topic. See the ART mailing list discussion for details

[fluffy]

OK - thanks and I agree.

[ajeanmahoney]

@adamroach, in the following sentence:

So, to the crux of this ticket: yes, JSEP would reference both. 8445 normatively, and 5285 informatively.

You meant RFC 5485 (ICE) instead of 5285 (A General Mechanism for RTP Header Extensions), correct?

The document currently lists 8445 (ICE) normatively and 5485 (ICE) informatively. So no change there.

It's my understanding that I should change the following:

Current (Section 5.1.1, Usage Requirements): * ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use a lite implementation; implementations MUST properly handle remote endpoints that do ICE-lite.

Proposed (text from @juberti with small tweaks): * ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use an older version of ICE or ICE Lite; implementations MUST properly handle remote endpoints that use ICE or ICE Lite as specified in [RFC5245].

[adamroach]

@ajeanmahoney -- Yep, that is all consistent with my understanding. (And apparently I'm going to carry that 5284/5485 typo around pretty much forever. 😄)

[juberti]

This mostly SGTM. For the specific text, I think we'll need to ensure that the reader is clear that remote endpoints may use RFC 5245 ICE and also ICE Lite (regardless of version). Perhaps something like the following:

* ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use a lite implementation;
implementations MUST properly handle remote endpoints that use ICE-lite. The remote endpoint may also use
an older version of ICE; implementations MUST properly handle remote endpoints that use ICE
as specified in [RFC5245].

[fluffy]

That looks good to me and make things very clear