Deciding between two choices

[Aaron Falk]

So, Melinda, I fail to see how midcom was "derailed" by the process
you described.  This sounds like a fine example of the process the way
it's supposed to work.  This is the rough consensus.  Missing, of
course, is the running code.  That doesn't mean that it's necessary to
implement all the permutations.  (Although, perhaps it would be worth
revisiting the wisdom of the decision to go with the solution you
chose after some implementation work is done.)  

My interpretation of the problem you are describing is how to heal the
devisions that occur when there are factions in a working group
arguing for different solutions.  This *does* seem to be a problem for
the IETF.  (Witness the recent bash-fest on IPv6 on the e2e-interest
list.)  This seems to me to be a matter of wg chair leadership.  The
chair needs to articulate why the importance of making a decision and
moving on outweighs the potential benefits from pursuing one of the
non-chosen decisions.  (Note, Melinda, I'm not faulting you at all on
this as I have not been following midcom and generally think you do a
great job as a communicator.:)

--aaron

Melinda Shore wrote:
> > I've heard, but have not personally witnessed, tales of competing
> > proposals de-railing other WGs.  Would anyone like to cite their
> > favourite example?
> 
> Hi, midcom again.  The task is to choose an existing IETF
> protocol to carry action and policy requests to middlebox
> devices.  We had five candidates, eliminated two, and were
> faced with the problem of choosing from among the three
> remaining.  Adding to the difficulty was the influx of
> people who suddenly found the problem of middlebox
> communication to be particularly compelling and, by the way,
> had strong opinions in favor of one or another protocol.
> 
> We had produced a protocol evaluation document and the three
> remaining candidate protocols were ranked closely but not
> equally, so what I ended up doing was putting the onus on
> the working group participants to demonstrate convincingly
> that the remaining top-ranked protocol couldn't do the job.
> If they did we'd move on to the next one, and so on.  As it
> turned out the problems with the top-ranked protocol are
> addressable and certainly not sufficient to render it
> unsuitable.  
> 
> The problem is this: we absolutely did *not* arrive at this
> decision by consensus, and I would say that it's a minority
> of active working group participants who are happy with the
> outcome.  The alternative would have been no decision at
> all, although some participants wanted to do a midcom
> implementation on each of the candidates to see how they'd
> work out, which would have left us having to make the same
> decision in six months but with participants even more
> invested in their favorite protocol.  At any rate we're left
> with a protocol that almost certainly is the best choice but
> that a substantial number of participants are unhappy with.
> It's not a great situation.
> 
> I think that clearly choosing from existing thingies is not
> something that can be done by consensus in cases where
> there's not already a clear winner.  We need to be able to
> come up with decision-making processes that work when we
> can't come to agreement otherwise.  Part of it may be
> learning how to frame questions better.
> 
> Melinda