Re: [mmox] IETF policy question

[Charles Krinke <[e-mail]>]

I dont get it. I dont see a controversy.

We have OGP *implemented*. We have HyperGrid *implemented*. We have MXP
*implemented*. To me, these are the serious contenders as they exist, folks
can use them, folks are using some of them.

Lets move forward and discuss:

1. How to extend these existing "implemented" interop notions to have
additional features.
2. Encourage other virtual worlds to make "implementations" that can be
tested and used to determine their "usefullness".

When there are additional "implementations", then we can and should increase
the scope of this discussion.

Charles Krinke
OpenSim Core Developer
OSGrid Director



On Fri, Mar 27, 2009 at 11:37 AM, Dave CROCKER <[e-mail]> wrote:

>
> 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
>
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>



-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director