|
On 1/22/16 01:33, Harald Alvestrand
wrote:
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 agree with many of your criticisms of the result of a quarter century of evolving requirements and feature sets, added incrementally to a protocol suite, with the intention of being backwards compatible at each step. On the other hand, I'm not sure anything more architecturally pure could have emerged from such an environment, either. Long-term protocol evolution tends to be messy. Time for SIP/3.0, anyone? ;-) I observed the DISPATCH process for much of the time of my engagement. The DISPATCH process is reasonably efficient .... at solving the wrong problem. DISPATCH has done a good job of perfoming the task it was put forth to perform, which was administrative in nature. Where you see a procedural bump on the way to working group formation, I see a vast improvement over what we had in the areas that historically homed real-time work. Traditionally, proponents of new work that didn't clearly belong to an existing WG would start a mailing list, try to attract a community of interest, spend significant time figuring out how to get their work noticed by the right parties in the IETF, and ultimately -- if they're lucky -- get enough attention from an AD to get them to sponsor a BOF. Then, they needed to write and complete a draft charter in preparation for the BOF. This would take many rounds back and forth with the AD. Then, many months (and lots of work) into this process, they would finally meet at a face-to-face meeting and present their charter. If they continue to be lucky, the feedback they get is actionable and concrete enough that they'd be able to fix the charter and work with the AD to get a WG for the next IETF. In many cases, however, either the changes indicated by charter feedback would be substantial enough that another BOF was called for, or the process of spinning up a WG took so long that they didn't get WG status the next time around. So, the time from wanting to bring new work to the IETF to actually having a WG was frequently on the order of a year or longer. That's not a technical problem; it's a process problem. And *that's* the issue that DISPATCH was formed to address. As a case study for DISPATCH, let's look at MARTINI. In September of 2009, Richard Shockey brought forth the requirement to allow bulk registration of SIP AoRs with a registrar. It was discussed on the DISPATCH list, and dispatched to its own ad hoc meeting at the November 2009 IETF meeting. By December 2009, the MARTINI working group was chartered to define mechanism for this work. Despite non-trivial disagreement around the proper technical solution, the WG finished its work and requested publication of the final mechanism in October of 2010. So, in less time than many pre-DISPATCH working groups took to have their first meeting, we went from problem statement to IETF last call. I concede that not all DISPATCH efforts are going to proceed as smoothly as MARTINI did; but prior to DISPATCH, this level of time efficiency would have been strictly impossible. If you want a more recent example, the first proposal for standardizing lossless codecs reached DISPATCH in May of 2015 (and note that the proposal was quite nascent; its proponent framed the conversation with: "Our preparations are not yet at the stage where we have created a formal draft or submission for the IETF. Before we proceed, we'd like to engage the IETF community in discussion of the specifications and suitability for IETF"). This proposal was discussed in July in Prague, and the CELLAR WG was chartered in November. I like the example of CELLAR in particular, for two reasons. First, it shows how low the barrier is before someone can bring their work to a large, receptive audience. Previously, you'd need a charter mostly done before anyone started paying attention. Secondly, it's not clear to me that this work would have ever found an appropriate audience in the IETF without the kind of onboarding provided by DISPATCH. I suspect that, absent such a venue, the CELLAR work would have never received sufficient attention to be taken on by the IETF. What the DISPATCH process fails to achieve is what a good directorate should have been doing Yep, because that's not what it is. You're complaining that my pipe wrench makes for a lousy hammer. I agree. Please leave my pipe wrench alone and find some more suitable tool for pounding nails. /a |