Re: [ogpx] VWRAP Draft Charter - 2009 09 01

Charles Krinke <cfk@pacbell.net> Sat, 05 September 2009 18:38 UTC

Return-Path: <cfk@pacbell.net>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE943A6866 for <ogpx@core3.amsl.com>; Sat, 5 Sep 2009 11:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.232
X-Spam-Level:
X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SARE_UNSUB18=0.131]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BxSuzNo+1x9 for <ogpx@core3.amsl.com>; Sat, 5 Sep 2009 11:38:49 -0700 (PDT)
Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id CF9653A6821 for <ogpx@ietf.org>; Sat, 5 Sep 2009 11:38:48 -0700 (PDT)
Received: (qmail 13238 invoked by uid 60001); 5 Sep 2009 18:29:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pacbell.net; s=s1024; t=1252175351; bh=NPyCCo09HH9bzcfxsXZAwLZdR90AfYS7G9stmUcKdMw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bBpQgeOT7IB7Vju3UL2LgUwcalXVuckjXXVq7mm0F2oPSm7Xdpi2fyOfgnmMs5oSx/9jUHBEG/uRI8sV/Ko+WB86SUA5BSmOko+LHfJJOgqMLqRkop85wZlR9Yh6pnsHkj98e3+6TwM5OIMe4YPhJj11i/+H+Y4iq9V7M9QLsXQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4xu1jXYnEEorHshyc5LvaWBVUquuWXsBzCfeKQT8Tmt/vAudVLmdAzNYba5ABIYEoQ0MzuaOHWLyi7Ug9dSmdkLH+kHzhQiGgEKEqq2r2D8ICsheRyMISWSxsO1BtMvufMK1ViZS7i1EomE+CRe7r0m+rj1smt9izJJT+cY4RzY=;
Message-ID: <53651.9521.qm@web82607.mail.mud.yahoo.com>
X-YMail-OSG: AmABKIEVM1k37tvJb8XcIB4YIe9fNlao7bSK3QsGqWJgwTnEXKj_fHHmJub.ftiMxQ7NjioUcF8iIuc1xF1OImsk4JY1oKYtPtB17NLaTFomVh3PT2ykBa.IraXsN4KYA4T8EbypY9cc46oO8H6Sdz5qpR8UJuI6XXpBeg.5qxr_k8phbtondFR8PSukZlsMxL1_Q1s1fJAnEmWZkINkFdAv6ZQJNQdt4k_esCez8qZcCE7G7eVEiNSyEkWzD40LmKU0euLZKtKclDu1oGRzWdGnlP4_BMzIoXn.HwK3YciTRIFGcCV5ZYNhx.AgST9U7_8LUk6fLV7iliVDxkNaFHi2IX8usm4suPjNIiFxYo8NgfgOJnchbw--
Received: from [67.120.11.69] by web82607.mail.mud.yahoo.com via HTTP; Sat, 05 Sep 2009 11:29:10 PDT
X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2
References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <f72742de0909011648l5bcfc98fm3aa2a80bf2f0e3c0@mail.gmail.com> <e0b04bba0909020641y7cb795b8ie167f8c4a035197e@mail.gmail.com> <20090902230338.GC6652@alinoe.com> <e0b04bba0909022028g68227199t86212294fe6faefc@mail.gmail.com> <20090904195822.GA15341@alinoe.com>
Date: Sat, 05 Sep 2009 11:29:10 -0700
From: Charles Krinke <cfk@pacbell.net>
To: Carlo Wood <carlo@alinoe.com>, Morgaine <morgaine.dinova@googlemail.com>
In-Reply-To: <20090904195822.GA15341@alinoe.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-758854381-1252175350=:9521"
Cc: ogpx@ietf.org
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Sep 2009 18:38:51 -0000

In OpenSim, we use a different set of acronyms for similar things. We dont have AD's or RD's, but we do have UGAIM and Region Servers.

In our case, UGAIM stands for the array of five servers known as the Userserver, Gridserver, Assetserver, Inventoryserver and Messagingserver.

Certainly, I can imagine analogs as our Userserver is very similar to an AD and our Gridserver is very similar to an RD, so I think we can get there from here, but I also see nomemclature as being a continuous source of frustration for all concerned for some time.

I guess there is no way out of this, so I would say, lets just move forward. Eventually, we will get down to the nitty gritty of logins across different grids from, for instance, SecondLife to OSGrid or ReactionGrid and back. In fact, as I recall, we have already proven OGP from both the SecondLife betagrid to an IBM SecondLife grid, from the SecondLife betagrid to an IBM OpenSim standalone and from the SecondLife betagrid to some regions on OSGrid, so I know we can get there from here.

Its always an experience traversing the floors on the "Tower of Babel" when we do one of these things and I find that just moving forward and getting into the details helps to avoid spending years getting too hung up on the nomemclature. 

So, good job in getting to this point and I would say "Full speed ahead and darn the torpedoes as we try not to get too hung up on the TLA's and FLA's".

Charles

p.s. TLA, an ambiguous term means either ThreeLetterAcronym or FourLetterAcronym.

p.p.s FLA, another ambiguous term means either FourLetterAcronym or FiveLetterAcronym

p.p.p.s Acronyms "love" conversations on the "Tower of Babel"






________________________________
From: Carlo Wood <carlo@alinoe.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Cc: ogpx@ietf.org
Sent: Friday, September 4, 2009 12:58:22 PM
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote:
> The problem you see is that a virtual world is much more than just a Region
> Domain.  It is a complete set of services of which the Region Domain service is
> just one.  Other typical services might be those of the Agent Domain (which
> provides identification and authorization services and possibly others), as
> well as asset and inventory services, IM and other communication services, and
> maybe several more.

Well... that is purely semantic. It is a way to define VW, but not one that
I've been using :/

For simplicity, assume that only two things are needed to create a complete
virtual world, like SL or OG: A Region Domain (RD) and an Agent Domain (AD).

Currently, without any interop, each administrative entity (or trust entity)
will need to provide both: an RD *and* an AD, otherwise they don't have a 
functional VW.

Your conclusion is that a VW exist of both 1 RD and 1 AD. But I ask you to
reconsider if that conclusion is correct, because it is based on the current
situation without any interop. Now "correct" might not be the correct word - heh.
Rather I should say: I ask you to reconsider if that definition is very useful.

Lets consider the following fictive case:

LL runs one RD and AD, called RD1 and AD1.
CB (Cable Beach) runs another RD and AD, called RD2 and AD2.
A user that authenticates with either AD1 or AD2 can travel to RD1 AND RD2,
completely symmetrical, keeping their respective AD1- and AD2- assets etc.
This is possible with the right policies, so for the sake of looking at
the usefulness of the above definition of VW, assume this is the case.

Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be another VW?
Or do you think it would make most sense in THIS case to speak of a single
VW?

I think this is what Infinity means when she says that "virtual world" cannot
be defined, because what could be perceived as being a VW is highly dependend
on the exact situation (and policies) and in certain configuration that are
not as clear as the current situation (no interop) or the above example (100%
interop).

In one of my first posts about this topic I stated that "virtual world" should
be considered to be the Region Domain (although I didn't use that term at the
moment) and be completely independent of the Agent Domain, based on typical
cases of abuse and griefing etc: if anyone annoys some other user, or breaks
almost any ToS, it will be region based; which is why I've always said that
any type of abuse can and should be handled at the sim (single region) level:
the estate owner and managers in SL, even, but that idea definitely extends
to "world administrations": the people running the REGION (domain) is the one
that should decide what is the local ToS and deal with abuse etc. That is
why I strongly argue to define "virtual world" as Region Domain, and leave
the AD out of it. Nevertheless, now I have the term "Region Domain" I don't
need "virtual world" anymore.

> In our new protocol, these services may either be implemented internally within
> a virtual world, or some might be implemented as external services offered by
> third parties, the choice being a policy and design decision for each world
> operator.  In all cases however, the virtual worlds are defined by a set of
> services, and not just by a Region Domain.

I'm afraid that is purely a matter of opinion. I agree that it is likely
that a single 'administrative entity' that runs a RD will also run an AD
and allow users authenticated with their AD visit their RD, but it is no
more than *likely*. There will almost certainly be service provides that
ONLY run an AD, and don't have a RD! And I can imagine that there will
be some that only run a RD and do not care about running their own AD.

Therefore, "virtual world" cannot be synonym for "the set of services
run by a single administrative entity" as you seem to argue, and at
the SAME time be argued to include an RD *and* AD at all times.

> This is easy to see by looking at a couple of archetypal examples in this
> space:
> 
> 
>   • Is Second Life a virtual world?  Undoubtedly.  Is Second Life just a Region
>     Domain (assuming it were implemented using VWRAP)?  No, of course not, SL
>     includes all of the services mentioned above, and others.

Of course, LL happens to run all services that are needed to create one
virtual world; there are no third parties they can hire from yet, so they
have to provide it all themselves.

But after SL implemented VWRAP they might decide to do away from one of
their services and only keep their RD. Unlikely, but possible.

>   • Is OSgrid a virtual world?  Undoubtedly.  Is OSgrid just a Region Domain
>     (assuming it were implemented using VWRAP)?  No, of course not, it
>     currently runs all the UGAIM services, which in a VWRAP context would
>     become similar to those of Second Life.

Exact same argument.

> So you see, the idea that has been floated which claims that "VW == RD" is
> completely wrong, and misrepresents what constitutes a "virtual world" despite
> the very clear examples before us.

If you want to put it that way (including everything above that you said) then
I have to side with Infinity: you cannot define a virtual world that way and
use it for useful discussions regarding VWRAP.

In the end, one virtual world as defined by "all services together to make
things work" will be, or can be, a mix of many RD's and many AD's with a complex
web of trust/non-trust between them that makes the concept of "virtual world"
rather fuzzy at best.

[...]
> As we move into analysis of the problem space, these issues will be
> disentangled and clarified and the protocols will be defined and evolve, but
> from the current OGP perspective there is no symmetrical relationship possible
> between VWs that could be described as "peering".  It is the asymmetry of the
> VW-RD relationship that has been the crux of the "no VW interop" issue.  For
> symmetrical peering, the protocol would need to mention at least two
> communicating VWs.

You can about peering with just two RD's and one AD, or one RD and two AD's.

> Of course the situation could change as the protocol evolves.  For example,
> once or twice we have heard mention that multiple ADs could be involved in some
> way, and it seems certain that communication services from multiple VWs will be
> merged because residents demand this.  This would start to take us into VW-VW
> interop territory.  However, there is no such thing in VWRAP currently, and
> it's not in the list of deliverables to include it, and therefore we cannot say
> that VWRAP will provide VW-VW interop at all.  For now. ;-)

I can't comment on that cause I didn't see VWRAP yet, but from the
charter and the comments on this list I'd think that full support
for interop between any number of RD's and AD's is intended.

-- 
Carlo Wood <carlo@alinoe.com>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx