Re: [mmox] Creating walled gardens considered harmful

[Morgaine <[e-mail]>]

I agree entirely Charles.  I see Opensim moving forward with various
different forms of interop at a very fast rate and without requiring any
kind of IETF standardization.

This is why I think that James Kempf's cautionary post needs to be
considered:  perhaps we should follow Opensim's lead and work on interop
directly and practically as you are doing, instead of potentially wasting
years of our lives developing a standard that could be made obsolete by
practical work such as yours even before we are finished.

It needs to be considered so that if we decide to reject the advice, we do
so with our eyes wide open and fully aware of the odds we face.

Your practical approach to interop may be better use of our time, so James'
advice to work out interop practically before seeking IETF standardization
deserves some thought.

For me, I think it hinges on whether we can get people in MMOX to cooperate
on finding common ground.  It has been an uphill struggle so far.  I will
spend more time on it, but there is a limit.


Morgaine.

PS. Your mention of OGP interop in Opensim is greatly overstated though.
Opensim *does* implement what there is of OGP, but there is extremely
little, and the little there is (login and teleport) works in one direction
only from Second Life.








On Fri, Mar 27, 2009 at 10:52 PM, Charles Krinke
<[e-mail]>wrote:

> OpenSim *is* an interop project. It started out as an interoperability
> project with SecondLife and has gained a significant amount of momentum over
> the last two years. Contrary to the mis-conceptions sent to this list,
> OpenSim is not a SecondLife clone, but rather an interoperable simulator.
>
> To date, the AWG (Architecture Working Group) of SecondLife has implemented
> this OGP and demonstrated interoperability with both OpenSim standalone
> regions and regions on one or more OpenSim grids, such as OSGrid.
>
> HyperGrid is also an implemented interop protocol and allows
> interoperability between grids using OpenSim and is deployed and in daily
> use.
>
> There is also MXP, another interoperability protocol, recently announced
> and is now implemented in OpenSim.
>
> So, OpenSim is *significantly* about interoperability and will encourage
> contributions of source for the benefit of all. And I hope to see
> contributions of implementations of other notions of interop as time goes on
> and less posturing about how a simulation should or should not be designed.
> The simulations *are* designed, implemented and deployed.
>
> In order to move forward, I believe we need to concentrate on how to
> interoperate between the existing implemented and deployed systems and get
> past whether one architecture is better or worse then another.
>
> Personally, I look at this group and hope we can get past all this
> posturing and more into *how* interoperate more completely between various
> virtual worlds.
>
> If SecondLife happens to be leading this charge on this group, fine. If
> someone else wants to show an implemented and functional interop protocol
> that folks can test and use, fine.
>
> Lets just move forward, not sidewise. Otherwise, this will be a waste of a
> number of folks time, and that would be a great shame.
>
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
>
> 2009/3/27 Morgaine <[e-mail]>
>
> That's a very well reasoned post, James.
>>
>> What do other people think about this?
>>
>> Shall we go back to our individual small-scale interop projects, see what
>> develops, and publish Informational RFCs based on actual working interop?
>> And then in 5-10 years' time, after one or more de facto standards have
>> emerged, come back older and wiser and try for an Internet Standard to unify
>> the segmented metaverse?
>>
>> James is very right that it would take many years of effort to do it now,
>> and also right that our work could be obsolete before it even nears
>> completion.  I'm sure that nobody relishes the prospect of wasting years of
>> arduous effort for nothing.
>>
>> For my part, I believe that doing *something* now has great practical
>> value, even if only for the incidental side effect that it pushes the
>> envelope of what virtual worlds can handle and achieve.  But James' advice
>> is worth noting.  The price may be too high at this time.
>>
>> Morgaine.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Mar 27, 2009 at 8:05 PM, James Kempf <[e-mail]>wrote:
>>
>>> Hi Jon,
>>>
>>> I was at the BOF on Tues. You probably don't know me but I worked in
>>> IETF for around 10 years, recently I haven't been attending IETF but I'd
>>> like to offer my opinion on your email and the prospect of any work on a
>>> virtual worlds interoperability standard succeeding in IETF. I also have
>>> had some experience with virtual worlds, I did some work with Second
>>> Life shortly after the client went OpenSource, and I'm involved with a
>>> small group in Silicon Valley (FountainBlue) that is trying to organize
>>> events to foster networking among entrepenurs, investors, and
>>> technologists interested in virtual worlds.
>>>
>>> My opinion is that any such effort will take years, and it will by and
>>> large be out of date from a market standpoint by the time it is
>>> completed. In other words, by any reasonable definition of success, it
>>> will fail. Your email below is an initial indication of why.
>>>
>>> Basically your company (OLIVE?)and Second Life/OpenSIM are competitors.
>>> There are many others out there that compete with Second Life/OpenSIM.
>>> In situations like that, where there is one company or group of
>>> companies that want a standard and no basic agreement with other
>>> competitors for the need of interoperability to their business,
>>> standardization efforts in IETF invariably drag on, since the IETF rules
>>> that everybody gets their say allow competitors whose technology is not
>>> up for standardiztion to disrupt the proceedings. This is not a question
>>> of morality or anything, it is just good business sense, and everybody
>>> does it. Nobody wants a competitor's technology to get the "Good
>>> Housekeeping Seal of Approval" that a standard confers.
>>>
>>> An example of the exact opposite - where competitors have collaborated
>>> to achieve a successful standard - is MPLS, which was described last
>>> night at the technical plenary. But MPLS was addressing an industry that
>>> already had maybe 20 years of technical/business development, where the
>>> business roles of service providers, vendors, and customers were more
>>> clearly defined. Virtual worlds are considerably less mature (even given
>>> the abortive work in the early/mid 90's on dedicated VR systems). So the
>>> competitive posturing among VW companies is naturally more intense.
>>>
>>> My opinion on what you guys should do is the following:
>>>
>>> 1) The SL/OpenSIM/IBM people ought to go off and form an industry
>>> consortium and recruit some experienced protocol and distributed systems
>>> engineers to help them design OGP. IBM certainly has many such folks
>>> working for with experience in IETF, protocol engineering, and
>>> distributed systems design. Once they have their interoperability
>>> protocol done, they can publish it as an "informational RFC" if they
>>> want, this is something any individual or group can do and it does not
>>> constitute an "Internet Standard".
>>> 2) You and anyone else in the OLIVE(?) community should get together and
>>> work on the kind of interoperability protocol that addresses the system
>>> architecture and business ecosystem that you want to develop. You, too,
>>> can publish your work as an informational RFC.
>>> <This will allow both you and the SL/OpenSIM folks to focus on
>>> interesting technical issues and the particulars of your individual
>>> systems, rather than fighting each other on IETF mailing lists and
>>> generating carbon emissions flying to meetings that don't really decide
>>> anything>
>>> 3) By the time these parallel tracks are complete, it will be 3-5 years
>>> on (instead of 7-9, if that, which an IETF standardization effort would
>>> take) and the technology and business of virtual worlds will be much
>>> further along. At that time, there might be more clarity whether a
>>> commonality of business interests exists between multiple groups of
>>> virtual worlds which would allow them to supress their competitive
>>> postures and collaborate on a Internet-wide standard.
>>>
>>> Finally, putting on my volunteer hat, my feeling is that there are some
>>> serious, unresolved technical challenges involved in making VW a
>>> mass-market product. My feeling is that interoperability between VWs is
>>> only peripherally important. Having some kind of tacit agreement within
>>> the VW technical community about what those issues are, having academics
>>> working on research solutions, and having companies, too, implementing
>>> and deploying competing solutions which could prove themselves in the
>>> marketplace would be much more productive than fighting about an
>>> interoperability standard.
>>>
>>>                        jak
>>>
>>> PS: FountainBlue is sponsoring a virtual worlds event in Sept. at which
>>> companies can come and put up tables with information about what they
>>> are doing. If anyone is interested in participating, please send me
>>> email off-list.
>>>
>>>
>>>
>>> > -----Original Message-----
>>> > From: [e-mail] [mailto:[e-mail]] On
>>> > Behalf Of Jon Watte
>>> > Sent: Friday, March 27, 2009 10:00 AM
>>> > To: Morgaine
>>> > Cc: MMOX-IETF
>>> > Subject: Re: [mmox] Creating walled gardens considered harmful
>>> >
>>> > Morgaine wrote:
>>> > >
>>> > > While the original idea came from Linden Lab, that is no stumbling
>>> > > block:  every idea has to originate somewhere.  OGP has the great
>>> > > merit of being all-embracing as a concept, once you see
>>> > that certain
>>> > > ideas like /teleport/ and /client endpoint/ are actually much more
>>> > > flexible than they might at first appear.  /Client endpoints/ on an
>>> > > OLIVE server could "easily" allow Second Life clients to
>>> > interoperate
>>> > > with OLIVE clients.
>>> > >
>>> >
>>> > So, now for the less rosy situation:
>>> >
>>> > Even with the definition of the three services that you enumerated:
>>> >
>>> >    1. /Identity transfer is negotiated to provide continuity
>>> > of identity
>>> >       across the change of environment./
>>> >    2. /Presence transfer is negotiated to discontinue
>>> > presence in world
>>> >       A and commence presence in world B./
>>> >    3. /Asset transfer is negociated in the A->B direction to allow
>>> >       assets from world A to appear in world B, or to deny
>>> > the transfer
>>> >       where appropriate./
>>> >
>>> > There is no actual interoperability achieved if those are
>>> > standardized.
>>> > For a user of any other virtual world platform than
>>> > SecondLife/OpenSim,
>>> > these services would give them zero value. Thus, for virtual world
>>> > platforms other than SecondLife/OpenSim, there is close to zero
>>> > incentive to implement these services. And, because there is close to
>>> > zero incentive to implement these services, there is close to zero
>>> > incentive to participate in the standardization effort.
>>> >
>>> > I think that this is a problem. I'd like to understand how
>>> > others feel
>>> > about the same thing. I could see a number of different standpoints:
>>> >
>>> > 1. "It doesn't matter if some platforms won't participate in
>>> > this model;
>>> > we only care about the ones who do." (This leads to the
>>> > self-selecting
>>> > clique problem, which leads to isolated islands of separate
>>> > interoperability)
>>> > 2. "We need reasonably broad adoption for a standard to matter, so we
>>> > have to change the problem statement until there is value in the
>>> > standard for a reasonably broad set of platforms." (This leads to the
>>> > "re-define what we are doing" problem)
>>> > 3. "If we start here, then we can build on that in the future, until
>>> > such time as more platforms will get benefits from the
>>> > standard." (This
>>> > leads to the problem of building things intended to be used by others
>>> > without any input on what their constraints are)
>>> >
>>> > I currently am of opinion 2. I perceived the initial
>>> > standpoint by the
>>> > AWG contribution as 1. If you are of opinion 3, how are you
>>> > going to get
>>> > the requirements right?
>>> >
>>> > I think that it's important that everyone who will contribute to this
>>> > work actually clarifies what their assumptions are in this regard (as
>>> > well as the use case/requirements regard).
>>> >
>>> > Sincerely,
>>> >
>>> > jw
>>> >
>>> > _______________________________________________
>>> > mmox mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/mmox
>>> >
>>>
>>
>>
>> _______________________________________________
>> mmox mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmox
>>
>>
>
>
> --
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
>