|
Recently, in a response to a Last Call on
<draft-campbell-art-rfc5727-update-02>, I wrote the following
on the IETF list: Objection: I find the DISPATCH style of review to be a horribly broken idea. I also find the use of the term "working group", and the procedures of working groups, for what is effectively a permanent review panel and a standing BOF venue to be counterproductive and destructive of getting work done. This document proposes recommending this method as a generic tool that can be used in areas outside of the limited scope of SIP extensions - something I think is taking a bad idea and making it even more harmful. (RFC 5727 already said it would do that, but the RAI area has not followed up on this particular bad idea from RFC 5727, letting initiatives like WEBRTC flourish outside of the DISPATCH process, so the damage done by DISPATCH has been limited.) I therefore object to this document being published as a BCP. These words were rather harsh, and were commented on as such. It seems best for the community that I spend some words on describing why I came to this conclusion. When I came to deal with WebRTC and the assocated areas, I believed (not having examined the area too closely) that with the SIP suite, which uses SDP and RTP, we had achieved a reasonably functional and architecturally competent real time communications suite. I was wrong. It turned out that a number of fundamental problems existed, including: * A lack of clarity on the connection between SDP and RTP - the word “session” was used at both layers, but represented different things. * A lack of consensus on how one negotiated session properties that applied in one direction only. * An SDP architectural misfeature that led to a completely bogus requirement that differing media types be carried on different UDP ports * A number of issues with use of addresses in signalling - including the formulation of rules like the “SDP patch-up offer/answer” for making one set of addresses (in m-lines) match up with another set of addresses (in ICE) * A general acknowledgement that certain fairly absolute rules, like “always use RTCP”, were widely ignored in the industry and couldn’t be depended on * A number of rules around SSRCs that were based on an operating environment that doesn’t exist in practice (multicast groups) - in particular SSRC collisions - which have made these identifiers much less powerful than they might have been. * A number of long-standardized extension features (CAPNEG in particular) that are largely ignored by industry due to complexity, but are still used to block other efforts by saying “why can’t you use X instead”. * A number of unfinished products (EKT in particular) that seemed to be a good fit for some problem - but somehow never seemed to cross the finish line. This list is far from exhaustive. We have been chipping away at the issues that mattered to the WebRTC effort, while attempting to make sure the issues we were not addressing did not affect the effort (by not using the features they referenced). I observed the DISPATCH process for much of the time of my engagement. The DISPATCH process is reasonably efficient …. at solving the wrong problem. The ideal DISPATCH task is a proposal to address a small problem (or paper over some deficency in the protocol for a certain set of cases). It allows the ADs to delay such a proposal for 3 months without any controversy (“until the next IETF meeting”), and for 6 months if it turns out to need a WG (“first DISPATCH, then you write a charter, then you meet”). (Sometimes such delay is a good thing; some bad ideas just need the time to die.) Once the proposal reaches a DISPATCH meeting agenda, it gets some review, it gets some comments, it gets some recommendation (maybe) - and then it can move on, if the proposers still have energy for the push, and if any of the experts in the area have bought into the idea enough to give it the guidance it needs to achieve non-conflict with all the other small patches people are working on. What the DISPATCH process fails to achieve is what a good directorate should have been doing: Taking a view of the whole area of the protocol suite, and noticing things like: * SIP is largely non-interoperable. It’s useful to connect islands of a single product while claiming standards conformance, and it’s easier to wrangle into some semblance of interoperability than proprietary protocols - but it’s not “plug and play”. * SDP is a world picture that is not capable of representing a significant subset of the interesting ways in which people want to interconnect. This means that solutions that use SDP have to work around SDP, not with it. * RTP is showing its age. Security is a bolt-on, and RTCP is more of an extension platform than it is an useful set of features in the base spec. It’s clear that the industry needs a robust, interoperable, secure protocol suite for real time communication. It’s also clear that the IETF is the logical venue for that to happen. But DISPATCH isn’t the way to get there. -- Surveillance is pervasive. Go Dark. |