Re: DISPATCH and strategies for standards maintenance

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 was wrong.
>
> It turned out that a number of fundamental problems existed...
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