Re: [rtcweb] Eric Rescorla's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS and COMMENT)

[Cullen Jennings <[e-mail]>]

Let me try and answer with the caveat that I may get this wrong and need to be corrected by my co-chairs...

TL;DR - The chairs recommend changing the ref in overview to point at 5245 instead of 5245-bis


here is the longer version.... 

First a side note on how we got here. Some of the reasons we set up dependencies  like they are is that many years ago we made guess about what order work would get completed on and, shockingly, some predictions of standards developments timelines were less than perfect. We also assumed that some new work was going to require changes in ICE but as that work went progressed, we largely figured out ways to make it work with existing ICE implementations. 

We are confident that overview does not actually depend on anything in 5245-bis but instead just depends on 5245. 

Next lets discuss trickle-ice. The WebRTC set of specs currently normatively depends on trickle ICE. There is some questions if trickle ICE might depend on 5245-bis. Some of the trickle ICE  authors do not think it does. One of the authors said the chairs asked them to ref 5245 instead of 5245bis as both tickle ICE and 5245bis would be done around the same time. In general, the webrtc chairs would prefer to make the WebRTC dependency cluster as small as possible. If trickle ice actually gets done before 5245bis, and it does not depend on any 5245bis features, then clearly is should be changed to just depend on 5245. The WG responsible for 5245bis and trickle ICE can figure out what they want to do as both theses drafts progress. Given there is a strong possibility that trickle ice will only reference 5245, we think it would be better if overview did not bring 5245bis into the WebRTC dependency cluster. If on the other hand, trickle ICE does end up depending on 5245bis, there is no harm, and no need to change overview to point at 5245. 

There are other drafts that are normative dependencies of JSEP and the WebRTC cluster that also point at 5245bis. When we consider the technical things these drafts need, it seems likely they can also reference 5245 instead of 5245bis. For example draft-ietf-ice-dualstack-fairness, draft-ietf-mmusic-ice-sip-sdp, draft-ietf-mmusic-sdp-bundle-negotiation, and draft-ietf-rtcweb-transports (which is with the RFC Editor). The argument for the others is roughly the same as it is with trickle ICE. 

Cullen (without review from my co-chairs but trying to represent what we discussed on our chair call)


PS - if you are trying to figure out some of the dependencies for the WebRTC cluster, you might find https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/?include_text=1 useful but it is not 100% accurate. 



> On May 11, 2017, at 7:43 AM, Eric Rescorla <[e-mail]> wrote:
> 
> Question for the chairs.
> 
> On Thu, May 11, 2017 at 12:44 AM, Christer Holmberg <[e-mail]> wrote:
> Hi,
> 
> What is the status regarding this?
> 
> Regards,
> 
> Christer
> 
> On 26/04/17 06:02, "Sean Turner" <[e-mail]> wrote:
> 
> >
> >> On Apr 23, 2017, at 14:44, Christer Holmberg
> >><[e-mail]> wrote:
> >>
> >> Hi,
> >>
> >>> ----------------------------------------------------------------------
> >>> DISCUSS:
> >>> ----------------------------------------------------------------------
> >>>
> >>> Your citation to ICE is to 5245-bis, but at least the JSEP editor
> >>>consensus was that WebRTC depended on 5245, so this needs to be
> >>>resolved one way or the other.
> >>
> >> Keep in mind that, no matter what draft-rtcweb-overview and
> >>draft-rtcweb-jsep explicitly say, both specs reference 5245bis
> >>*IMPLICITLY*, e.g., via draft-mmusic-bundle, draft-ice-trickle etc... As
> >>I have indicated in the past, it would cause confusion to reference both.
> >>
> >> So, I think we shall reference 5245-bis everywhere (I also thought we
> >>already decided no that in the past)-
> >>
> >> Regards,
> >>
> >> Christer
> >
> >/* bike shed alert:
> >/*
> >/* Assuming you¹re of the mind that a bis/updates draft is
> >/* signaling to all implementors of the original RFC that the
> >/* intention is that all implementations be updated then it¹s
> >/* a bit more than implicit.
> >
> >spt
> >
> 
>