Re: DISPATCH and strategies for standards maintenance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]