Date: Sun, 14 Apr 2002 14:59:39 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Message-ID: <3CB9D19B.7C0530F7@cs.columbia.edu>
| A spec in a WG work item
| generally gets some amount of exclusivity, in that the working group
| isn't going to consider a similar spec by a competing set of authors.
| (There are exceptions in highly contentious working groups, obviously.)
| However, that only works if the authors deliver on time.
It is also a large part of the reason why things don't get delivered on
time. Not (usually, though even here sometimes) new versions of drafts,
but the completed product, that is what the milestone is about.
That is, because there is just one spec being written, it has to actually
catch the consensus of the group, and sometimes that is very hard to
determine. Writing one set of words is easy, but if half the working
group then object, it has achieved little.
In a commercial environment, there'd be someone "higher up" who can use
one mechanism or another to resolve those differences "OK, we'll do it
this way", which everyone would then have to go along with (or leave).
The IETF doesn't have, and can't really have, any such arbiter. On
occasion when things are very deadlocked, for very long times, various
schemes have been used to break out, but most of the time, it is just
time itself that eventually erodes one side's opposition, and allows things
to eventually proceed (either because of eventual frustration, or because
other events eventually show one solution or the other to be superior).
Of course, this means that the milestones (which generally couldn't have
predicted the impasse in advance) tend to fall by the wayside. I'm not
sure there is any very good solution to this.
I suppose that we could do what most other similar bodies have done, and
simply write specs that satisfy everyone, with every conceivable option
included, and interoperability only by random chance - but I don't really
believe that any of us wants to start down that path.
So, it is all very well to tell working groups that they have to meet
their milestones, but it doesn't work unless some kind of (internal working
group) conflict resolution mechanism exists, and as much as possible, we
don't want that to turn into trade offs.
Shutting down working groups when they fail to meet milestones is an option,
but it certainly doesn't help that other working group you mentioned, which
is waiting on the results of the one which is deadlocked.
kre