Re: [vwrap] Comments on http://tools.ietf.org/html/draft-ietf-vwrap-intro-00

[Meadhbh Hamrick <[e-mail]>]

VWRAP is a protocol. it is not an implementation. the protocol DOES
NOT require you to adhere to any one single deployment model. what
we're discussing here is the degree to which different deployment
models are highlighted as examples and which will be used to define
the problem domain for the protocol.

on this list we have informally use the ostensive definition to
describe deployment patterns for VWRAP. that is, we've said things
like "look at how second life does it." or "we want to do it like
OpenSim."

there's a problem with this in that our protocols need to describe the
mechanisms used to communicate. we cannot say "we're doing things like
HyperGrid" and be finished. rather, we need to identify those features
of hypergrid that we like, then the features of traditional opensim,
then the features of second life. on top of that we can hypothesize
some features we like that are not demonstrated in any existent
system.

morgaine has complained that we have not mentioned "the tourist model"
in the specifications. while it's true we have infrequently used the
term "tourist model," we have defined a system by which the tourist
model, the walled garden model and the hypergrid model can all be
represented. what we don't do is say... "hey look! here's
hypergrid!!!!"

the way we describe different deployment models is by describing
trust, service extent and service establishment.

for the sake of argument, let's call "trust" a collection of
identities, each with "privilege" to perform a set of operations on a
set of "sensitive resources". (let's table the discussion of
capabilities and X.509 certificates, that are carriers of trust, for
the moment.)

now let's call service extent the collection of hosts over which some
_data_ is considered valid.

service establishment is the process by which a client (not always a
user agent) gets a capability to access some data or manipulate state.

so for the traditional linden legacy, walled garden model, it's easy.
all server entities are managed by the same organization and therefore
inherently trust each other. user agents demonstrate their
trustworthiness by providing a username and password. service extent
is also simple; data about region adjacency is shared across the
entire, closed world. service establishment is easy too, the client
logs in and the authentication service (which the client implicitly
trusts) gives the client a list of capabilities for various services.

we can refine this model by adding trusted third party services to the
mix. let's say that i, as a grid deployer, don't want to implement an
asset service (or a chat service or a map tile server or a ... ) so
rather than running my own asset service, i contract with a trusted
third party (call it "assets R' us".) out of band, i make an agreement
with assets R' us and they provide me with some protocol endpoint from
which i can request an interface for specific user's assets. i (the
auth service) turn around and provide the user specific asset access
endpoint to the client.

in both models, the client does not need to be aware that there is a
trust relationship between me (the auth service provider) and assets
R' us (the asset service provider)

this model is vaguely similar to hypergrid or OSGrid where there are
some central services and some services that are distributed.

but this model gives a lot of power to the auth service. it also
relies on a strong trust relationship between the auth service and
other service providers. what if you want to be able to point your
viewer just anywhere and (modulo local region policy) your avatar
would just rez there. the client could tell the region where to find
it's assets (again modulo local region policy like "i won't rez assets
from the pirate bay asset service, but i will rez them from amazon's
asset service.") there's nothing wrong with this model, and despite
what you've heard, it's been supported from day one.

why is there such consternation then? because when people look at the
drafts they're expecting to see functional specifications for virtual
worlds. what they see instead are protocol descriptions. you will not
see us mention "tourist model" or "open sim" or even "linden lab" in
the charter, the intro or the normative specifications. this is
because using the ostensive definition for interoperability is
"wrong." if we said, "VWRAP is just like hypergrid" then we would need
hypergrid to stop evolving. ditto for second life and pre-HG opensim.

so in conclusion, we WANT to support multiple models, not just the
tourist model. not just the linden model. not just the hypergrid
model. we WANT to be able to specify a protocol that is useful for
each of these virtual world models.we WANT people to be able to play
around with the model and use bits and pieces of the protocol as they
see fit.

we WANT to support multiple instances of virtual worlds and give
individual deployers the decision of which bits of the protocol they
wish to support. like if OpenSim decided to use VWRAP auth and asset
access, but not VWRAP teleport, that's still okay.

it does, however, degrade the ability of any system to talk to any
other system using only the protocol defined by this group. but that's
probably okay. for instance, did you know that 802.11b is not exactly
the same as WiFi? WiFi (and WPA) are "profiles" of the 802.11?
protocol series. WiFi specifies which options of 802.11 are acceptable
for interoperability. i think we're probably headed the same way with
VWRAP. VWRAP as a collection of underlying protocols will be specified
to the degree that software developers can write middleware
implementing the standard(s). Deployers or groups of deployers and
other software developers will then step in and say... "okay... for my
grid, we're using these options..."

it's not big-I interoperability, but given the fact that even our
small group is so fractured, i think we may want to shoot for little-i
interop first.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Sun, Sep 19, 2010 at 5:29 AM, Fleep Tuque <[e-mail]> wrote:
> Hi all,
>
> I'm sure I need to go back through and re-read some of these documents to
> find definitions, but I must be missing something entirely.  I've been
> lurking on this list for some months and the statement that "VWRAP is not
> now, nor has it ever been a protocol to enable
> interoperability BETWEEN virtual worlds" took me completely by surprise.
> I've been under the impression that was the entire point of this effort!
>
> The OpenSim model described by Cristina, and the concerns raised by the
> message at the start of this thread, pretty closely reflect my views and
> concerns.  A consortia of universities is developing in which each
> university will operate its own "world" - using their own access and
> authentication schemes, internal system architecture, etc. - but allow our
> researchers/students to be able to connect and go to the worlds of other
> participating members to collaborate on research projects.  We need
> protocols to help establish the ground rules for that connection, and what
> the baseline requirements are for our "world" systems to be able to
> communicate with one another, but ideally to be as minimally
> intrusive/restrictive as possible.
>
> Part of the interest in this experiment is similar to the "laboratories of
> democracy" model in which each institution CAN and SHOULD do its own thing
> internally so we can see what sorts of best practices and innovation in
> internal system design emerges.  (In fact we have little choice, since each
> institution is bound by different laws and policies governing things like
> authentication and student data.) In our use case, this is not a "tourist"
> model OR a "walled garden" model - it's both!  Each institution
> intends/needs to have areas of their "world" that are off limits to other
> institutions, and some areas that are accessible to members of the
> consortia.  Figuring out which bits we need to pass back and forth to make
> this work is, I thought, what VWRAP would be addressing.
>
>
> I will go back through and re-read the source documents with Meadhbh's
> comments in mind, but I wanted to chime in and say Cristina's concerns and
> perspective pretty closely represent my interests as well.  And I think it's
> a mistake to frame the conversation as a "tourist" model vs a "walled
> garden" model even hypothetically, since as far as I can tell, we are much
> more likely to see hybrids of the two than any pure implementation of either
> in the ecosystem of worlds that Cristina rightly points out are already
> developing.  In any case, a protocol that assumes only one world seems on
> its face of very little value to _anyone_ if the point is not to have
> interoperability between worlds using the protocol!
>
>
> Confused and befuddled,
>
> - Chris/Fleep
>
>
> Chris M. Collins (SL: Fleep Tuque)
> Project Manager, UC Second Life
> Second Life Ambassador, Ohio Learning Network
> UCit Instructional & Research Computing
> University of Cincinnati
> 406E Zimmer Hall
> PO Box 210088
> Cincinnati, OH 45221-0088
> [phone]
> [e-mail]
>
> UC Second Life:   http://homepages.uc.edu/secondlife
> OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php
>
>
>
>
>
>
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>