Hi, Harald.
First, thanks for your clarifications. I have some comments inline:
On 22 Jan 2016, at 1:33, Harald Alvestrand wrote:
[...]
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.
I don't dispute that there are many issues within our suite of real-time
communication technologies. I take the basis of your argument to be that
DISPATCH has either hindered attempts to solve those issues, or at least
hasn't helped.
I think the real issue is that the community has not had the will to do
massive protocol fixes and replacements in this area--probably for both
good and bad reasons. There's a lot of inertia in the need for backwards
compatibility, and there's lots of legacy products out there. I think
conversations on ways to improve that would be interesting, and maybe
even useful.
But I don't think DISPATCH (either as a working group or a process) is
the problem here. You argued that DISPATCH is only suited for solving
small problems. As a test case, let's look at the RTCWEB working group.
This is not a small effort. It effectively replaces much of the RTC
signaling architecture. It also requires tight cross-SDO coordination
with the W3C. I think rtcweb falls into the category of "ambitious
changes to modernize IETF technologies" if anything does.
As far as I can tell from the mailing list archives, discussion of that
work started in Nov 2010 (probably at IETF79) when you submitted drafts
to DISPATCH. There was a BoF at IETF80, and a working group formed in
May 2011. I recognize that the rest of the world might think that was
slow, but it was pretty quick by historical IETF standards. I think it
likely that DISPATCH shortened the process, possibly cutting out the
need for at least one additional BoF.
So, my question is: What would you like to be different? Do you think
the conventional (non-DISPATCH) IETF approach to large new efforts would
have worked better? Do you think we need something different than either
of them? Can you describe how you would have expected the chartering of
RTCWEB to have gone without DISPATCH?
Thanks!
Ben.