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

[Dan Olivares <[e-mail]>]

+ 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
>
>