Re: [mmox] IETF policy question

[Dave CROCKER <[e-mail]>]

Heiner Wolf wrote:
> Assumed there are multiple systems with incompatible architecture,
...
> What would the IETF do?
> 1. task one of the sub-groups to standardize one of the
> protocol/architecture variants, 
...
> 2. do not standardize at IETF level, 


Folks,

Hi.  Sorry for not responding sooner. Your question is a good one to ask at the 
start of an interesting effort from an established and diverse community, since 
the likelihood of competitive proposals is pretty high.

Alas, the simple answer to your question is that there is no simple answer.

So I will provide some discourse which represents both my own view of the way 
this ought to play out and my own view of why it might or might not happen that 
way.

For all its increasing number of formally documented rules, the IETF is really a 
body of people, including ADs and the IESG, and specific decisions often come 
down to what their personal assessment of the right choice is.  Choices which 
one person might think to have a blindingly obvious correct outcome can be, and 
often are, interpreted wildly differently by others, including ADs.  This is 
both a distinctive strength and a distinctive weakness of the IETF...

For reference, at the Thursday evening IETF plenary, a version of your question 
was commented on, during a presentation about MPLS, which is a successful 
lower-layer service for optimizing the handling of packets riding over certain 
kinds of media.  The presentation was about the factors that helped the protocol 
succeed.

One of the comments was about the presence of competing specifications, for 
various components of the MPLS service and that the competition often helped 
/improve/ individual specifications.  Competing efforts split the available 
focus and the allocation of resources and they can confuse the market; so it's 
difficult to believe they can actually be a Good Thing.  Hence, competing 
proposals are something that no one likes, and that everyone would prefer to 
believe should be resolved quickly, by fiat if necessary.  The uncertainty and 
potential cost and delay in letting the market do the choosing, is not all that 
appealing.

However the comment in the presentation was that it is, in fact, better to let 
the market decide:  Pre-emptive selection during standardization can be 
premature, because it is based on too little practical knowledge.

This matches my own view of what should happen:

      Let each competing proposal form its own constituency of supporters, run 
each through the process of creating, testing and deploying its preferred 
specification, and let the market decide the winner (or winners.)

      IMO, an administrative decision, down to a single choice, before the 
process has gone through these steps, is subject both to ignorance and politics.

      Ignorance because there often is not enough information to fully 
appreciate the technical, operational or efficacy subtleties of a proposal. 
Politics because it entails a Grand Decision by a central Grand Authority. 
Concentrated authority invites concentrated lobbying.

Most of the standards spec competitions I've seen -- that have been allowed to 
play out on their own energy -- actually resolve reasonably soon, during the 
specification or testing process: one or another competitor fails to maintain 
enough community support or fails to do the hard work of technical specification 
and vetting the results.  In other words, the proposals failed on their merits. 
  The put-up-or-shut-up pragmatics of all this ought to appeal to anyone 
interested in delivering real value to the community...

All that said, there is the earlier question:

      Should competing proposals seek to merge?

The glib answer is that seeking world peace is always a laudable goal, but it 
has a problem being practical... In my own view the practical answer is that it 
depends on the nature of the differences.  If the proposals differ on matters of 
form, such as using periods rather than semicolons, then yeah, they need to 
merge.  Not should.  Must.  The differences are not real matters of substance 
and the community can't really care about such minutiae.

On the other hand, if the difference is a matter of paradigm -- such as having a 
central server versus a true peer-to-peer (with no intermediary) model -- then 
the difference is really quite fundamental and the answer is that it's almost 
never possible to merge them.  Or at least not without destroying the essence of 
one or both proposals.  Again, this is IMO.

So go ahead and have the merger discussion, since it is always possible that 
some common ground might be found, and even if it isn't, mutual understanding 
will improve and sometimes the details of one or both proposals will improve. 
But do not artificially force them to reconcile.  It will be an unnatural act 
and no one will like the offspring.

Now as for how competing proposals are likely to be handled in the IETF, the 
answer as I said at the start is not obvious.  Area Directors differ on their 
handling of such competition.  On the average, I strongly recommend developing a 
vigorous community of support and participation -- based on work, not lobbying 
-- along with discussing the matter with Chairs and ADs.  Community momentum 
based on doing the hard work can, and often is, the most compelling argument for 
being allowed to continue.

Again IMO, when the differences are in paradigms, the competition is between 
efforts that should have separate working groups.  At best, it is extremely 
distracting to have them in the same wg.  At worst, it encourages fighting 
rather than working.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net