Re: [ogpx] +1 on the charter (was: RE: An example to show the problems with defining an OGPX/VWRAP virtual world)

[Infinity Linden <[e-mail]>]

it should probably go without saying that i +1 the charter, but for
completeness sake, let me just say...

+1 on the charter

On Wed, Sep 2, 2009 at 3:25 PM, Dan Olivares<[e-mail]> wrote:
> + 1 on the charter also
>
> Regards
>
> Dan
>
> On Wed, Sep 2, 2009 at 5:07 PM, Morgaine<[e-mail]> wrote:
>> +1 John.
>>
>> I'll try to keep the nil trust domain use case in focus before us as the
>> work proceeds, and hopefully the periodic syncs with Cable Beach features
>> will merge in fine when you can dedicate time to it.
>>
>> Thanks for that input. :-)
>>
>>
>> Morgaine.
>>
>>
>>
>>
>> ===================================
>>
>> On Wed, Sep 2, 2009 at 9:40 PM, Hurliman, John <[e-mail]>
>> wrote:
>>>
>>> You have to start somewhere. It seems like the core contributors to VWRAP
>>> are primarily interested in the use case of explicit trust domains, so they
>>> will be in a good position to carefully think through this use case and
>>> create a strong spec for it. Asking someone to spend any significant amount
>>> of effort on a use case that they have no demonstrated need for will get you
>>> a poorly though through spec at best. The explicit trust domain work that
>>> VWRAP is focusing on also does not preclude other groups from focusing more
>>> closely on the nil trust domain use case. That’s the domain that my work
>>> (Intel’s Cable Beach) is primarily interested in, and so far I feel that
>>> Intel’s work and VWRAP’s plans have nicely paralleled each other. With some
>>> effort, hopefully they will be able to merge in the future.
>>>
>>>
>>>
>>> This is why I don’t have any strong feelings on the specific wording of
>>> the charter. The primary contributors to VWRAP know what they are working
>>> on, and the capabilities (no pun intended) of the final product will speak
>>> louder than the original charter. Although there is always room for more
>>> closely defining your goals and requirements, I’m in favor of a +1 on the
>>> current charter and moving on to the next step. I can’t personally commit
>>> any development effort to VWRAP work at this time, but I will continue to
>>> periodically sync Intel’s Cable Beach work with the VWRAP work and aim for a
>>> merging of features in the future.
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Morgaine
>>> Sent: Wednesday, September 02, 2009 7:27 AM
>>> To: [e-mail]
>>> Subject: Re: [ogpx] An example to show the problems with defining an
>>> OGPX/VWRAP virtual world
>>>
>>>
>>>
>>> Magnus' interesting analysis effectively reaches the same conclusion that
>>> various people reached in MMOX.  I wrote a short summary of it back then --
>>> http://www.ietf.org/mail-archive/web/mmox/current/msg01307.html .  Trust
>>> agreements will not build the metaverse, but only balkanize it.
>>>
>>> In the end, the only trust domain likely to bloom explosively in the way
>>> that the Internet and the web did is the nil trust domain, so all this
>>> emphasis on trust agreements is largely immaterial to the worldwide spread
>>> of virtual worlds.  Trust agreements on a global scale become completely
>>> meaningless, as no trust is actually carried.  Schneier's point about
>>> "security theater" applies here completely.
>>>
>>> Fortunately, as David Levine has said a few times, trust agreement
>>> technology does not preclude nil trust, so we can work with this.  However,
>>> it will be extremely important to ensure that the nil trust mechanism is
>>> actually catered for in practice in VWRAP, rather than just in theory.
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>>
>>>
>>> ===============================
>>>
>>> On Tue, Sep 1, 2009 at 11:06 AM, Magnus Zeisig <[e-mail]>
>>> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> Sorry to crash in and sorry if my below rambling is useless, a
>>> misinterpretation, or, even worse, only mess up things even further. But I
>>> believe an example might clarify things a bit to at least some readers. If
>>> my below example is wrong, perhaps someone with a better understanding than
>>> me could correct it or provide another example.
>>>
>>> I think one of the problems with the definitions of "virtual world" and
>>> related terminology on the list is that it's easy to lock it to the existing
>>> models, like Second Life or OpenSimulator, and not realizing that future
>>> models might be quite different. If I understand the intents and early
>>> definitions on this list right, a very small but still rather complex
>>> OGPX/VWRAP model might look like this:
>>>
>>> Protocols
>>>
>>> * Five geographically adjacent simulators/regions in a rectangular grid:
>>> "R11" (top left), "R12" (top right), "R21" (middle left), "R22" (middle
>>> right) and "R3" (bottom left and right, since no requirement for equal-sized
>>> or -shaped regions exists).
>>> * Four avatars: "A1", "A2", "A3" and "A4".
>>> * Three simulator/region owners/managers: "M1" handling "R11" and "R22",
>>> "M2" handling "R12" and "R3", and "M3" handling "R21".
>>> * Three asset/inventory service providers: "S1" catering to "A2", "A3",
>>> "R11", "R22" and "R3", "S2" catering to "R12" and "R21", and "S3" catering
>>> to "A1" and "A4" (one region owner may employ more than one asset service,
>>> like "M2" does with "S1" for "R3" and "S2" for "R12").
>>> * Two authentication service providers: "L1" catering to "A1", "A2" and
>>> "A4", and "L2" catering to "A3".
>>>
>>> Note that some of the above entities may be the same company or site
>>> providing different services, e.g. "Virtual World Services, Ltd." managing
>>> both "M1", "S1" and "L1".
>>>
>>> Policies
>>>
>>> All simulator/region owner/managers, asset/inventory service providers and
>>> authentication service providers share a common domain of trust, with the
>>> following exceptions:
>>> * "M2" doesn't trust "S1" (e.g. owing to previous experiences of malicious
>>> content).
>>> * "S1" doesn't trust "M3" (e.g. owing to "M3"s refusal to sign an IP
>>> agreement).
>>> * "M1" doesn't trust "L2" (e.g. owing to a too loose control when
>>> accepting new users).
>>>
>>> Results
>>>
>>> Seen from the avatars' points of view, this means:
>>> * "A1" can move freely with all attachments and inventory through all the
>>> regions.
>>> * "A2"  can move freely through all the regions but can't bring
>>> attachments and inventory to "R12" and "R3" owing to "M2"s distrust for
>>> "S1", and "R21" owing to "S1"s distrust for "M3".
>>> * "A3" can only move to regions "R12", "R21" and "R3" owing to "M1"s
>>> distrust for "L2", and can't bring attachments and inventory to "R12" and
>>> "R3" owing to "M2"s distrust for "S1", and "R21" owing to "S1"s distrust for
>>> "M3", i.e. is not fully operational in any region. Also, the world is
>>> geographically split since "R12" and "R21" is only connected through a
>>> corner where it can't cross but require teleportation.
>>> * "A4" can move freely with all attachments and inventory through all the
>>> regions.
>>>
>>> So, to "A1" and "A4" this is a great virtual world with five fully
>>> functional regions, to "A2" it's a hobbled world where it's ruthed (forced
>>> to some generic appearence) in three out of five regions, and to "A3" it's a
>>> lousy, splitted world with only three regions in which it's all ruthed. But
>>> what really constitutes the geographic "virtual world" in this example? The
>>> five regions "R11", "R12", "R21", "R22", "R3", the three regions "R12",
>>> "R21", "R3" where all avatars can go, or no region since there is no region
>>> that is fully functional to all avatars?
>>>
>>> I guess this is part of the reason why the exact definition of e.g.
>>> "virtual world" and "interop" is not made, because the aim of the working
>>> group is to provide the technical specs necessary to enable, but not force,
>>> the communication between such entities as mentioned in the example above,
>>> while policies might make up a totally different infrastructure and
>>> impression of what the "virtual world" or "virtual worlds" and "interop"
>>> are, or at least appear to be to the end-users (avatar owners).
>>>
>>> Best regards,
>>> Magnus
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: 9.8.3 (Build 4028)
>>> Charset: utf-8
>>>
>>> wsBVAwUBSpzyJ+5MlU9XyaiSAQgTyQf+MjeSs8iKdSWHKKPASzwa9KjmYtj8ojUg
>>> +nqiaGtaB7lWC/Lq1PUGxMXdJvUd4AhCL96wvawWQzxAQmYYk7n0hjvs6RKub2cm
>>> bhuvhHbEtn/9uD1tdBJvm0x+Q1ZFr6nqE2XV9cXEwlGx32/wl9aP0/wejAouqCZM
>>> a9YQv5ceE5B3zJn54TdbFPXX8V6OZ7jtiUplP2erhUg0hkzOjVYkwt1f5G9NJhW8
>>> p2YcTYibC0mnnu/ATzVojMhxMiQpwxRH7695TobDUdBCz48+ix1tZvkLdk9o2t2u
>>> JodGIkTtd+mFdYOtUNbaScrTs02exahKfqD81gaEYCcLfO+J14XkkQ==
>>> =FsIQ
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> ogpx mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>
>>>
>>>
>>> _______________________________________________
>>> ogpx mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>