Re: [ogpx] where does VWRAP fit?

Morgaine <morgaine.dinova@googlemail.com> Sun, 13 September 2009 20:08 UTC

Return-Path: <morgaine.dinova@googlemail.com>
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 5B17C3A659B for <ogpx@core3.amsl.com>; Sun, 13 Sep 2009 13:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=1.179, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001]
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 eFku49fRymBj for <ogpx@core3.amsl.com>; Sun, 13 Sep 2009 13:08:53 -0700 (PDT)
Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id B20213A686D for <ogpx@ietf.org>; Sun, 13 Sep 2009 13:08:52 -0700 (PDT)
Received: by ewy3 with SMTP id 3so1920285ewy.42 for <ogpx@ietf.org>; Sun, 13 Sep 2009 13:09:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=NnD7mw4QI5qiX0ns6HIrF26rp5x/AslzCtOcZCKtyzE=; b=ryl0VZZE7bSqfAvZROBAJUUHgarGP5a0rOGVCoRLBmbIFoQ4X5IoiPuJV62EYEyJUq UPpydZsEtrWQkRxL8jTuuMwkuLMIQazy2vXlOtIferFVrNRMXW3sXa/raot4pqVKjAzr pF1uhzQgD6n7XFx8ZKln93iZcWOu8IK7VzBV0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=dtpVh2sQ3RaozI0D0J+Xygl3pp9pVc+E1zALaRejpoD5ifcLXMNrZ9te0AZcy4Zikj 2djILqbT/J//qjCH2TMQc4qhnqvmUwirj0OEDR99SFF82b11c9ZezkXkswTDbAsI2lUe 9vvgVYfDpt8LYOgyxBj9WjQu0M/ssXfIaTu8U=
MIME-Version: 1.0
Received: by 10.216.13.211 with SMTP id b61mr984303web.91.1252872570434; Sun, 13 Sep 2009 13:09:30 -0700 (PDT)
In-Reply-To: <55607BD7-7F96-48A5-856D-59114BB84C3D@americafree.tv>
References: <382d73da0909060904h7b666bdqc40ce151ce0d241a@mail.gmail.com> <e0b04bba0909110036r3337f945tb93955fbac0c5798@mail.gmail.com> <f72742de0909110915q61e051a8yeb623787a2ddd719@mail.gmail.com> <e0b04bba0909122355u27cb986dta052b6b79ba5e71@mail.gmail.com> <876204.77782.qm@web82603.mail.mud.yahoo.com> <e0b04bba0909131048w5852f923u323f57f5bf7dad85@mail.gmail.com> <171805.77315.qm@web82606.mail.mud.yahoo.com> <55607BD7-7F96-48A5-856D-59114BB84C3D@americafree.tv>
Date: Sun, 13 Sep 2009 21:09:30 +0100
Message-ID: <e0b04bba0909131309w77f248fbh291143a34086bc2@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary="0016364d295382748304737b20c1"
Subject: Re: [ogpx] where does VWRAP fit?
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: Sun, 13 Sep 2009 20:08:57 -0000

Marshall, having worked at the network operations centre of an ISP for many
years and dealt daily with AS's, I have to say that your analogy is near
perfect, and the best yet, by far.

Yes indeed, VWs and ASs are quite analogous as seats of policy and choices,
and cross-VW interop is very much about peering between VWs with clients as
an intermediary.  But to be able to peer between ASs you have to be able to
refer to the ASs in the first place, and not invent a "single AS" out of
thin air that precludes this.

Peering between VWs looks like a very effective angle from which to approach
this work.


Morgaine.






==============================================

On Sun, Sep 13, 2009 at 7:36 PM, Marshall Eubanks <tme@americafree.tv>wrote:

>
> On Sep 13, 2009, at 2:21 PM, Charles Krinke wrote:
>
>  Well, you bring up some really good points. Personally, what I have been
>> doing is ignoring all the discussion of what the words mean and focusing on
>> my end goal which is the interoperability between similar, autonomous,
>> distinct grids all using compatible protocols.
>>
>>
> I think that metaphors can be very important in cases like this, so here is
> one I will throw out for consideration after reading through this mail
> thread. If someone else has made this metaphor, I apologize (but I did
> look).
>
> I look at the "virtual worlds," from an Internet perspective, as analogous
> to Autonomous Systems. An Autonomous System (AS) is a network that has its
> own routing policy, its own internal services, etc. An AS gets to determine
> what happens inside of it, and (in connection with the other party) gets to
> determine peering policies with its peers. (Note that an ASN is not
> necessarily the same as a company, university or other real-world entity -
> some companies have more than one, other ASs aggregate traffic from several
> networks.) At the largest level, the Internet is a network of ASNs connected
> by the Border Gateway Protocol (BGP) .
>
> From this standpoint,  SecondLife, OSGrid,  etc., are Autonomous Virtual
> Systems (AVSs), and, just as BGP determines how packets pass between ASs, it
> seems to me that VWRAP should provide a gateway protocol to determine what
> happens as avatars pass between AVWs. In this metaphor, some services might
> be automatic if you are allowed in, some might require an invitation
> (similar to the way that firewall passage typically requires an invitation
> from the inside), there might be true peering between AVSs of similar size
> (where avatars or services are allowed free interoperation between the two
> AVSs), and relationships between AVSs of different sizes might require
> payment for the smaller AVS).
>
> This metaphor, while similar to the idea of Virtual Worlds as countries or
> nation-states, it seems to me is better aligned with the way things are done
> on the Internet, and close to the realms where we have working code and
> experience.
>
> Regards
> Marshall
>
>
>  So, ... if the words get in the way, it is my intention to roll right over
>> them and ignore them.
>>
>> If that is an issue, then we need to go back and agree on the words.
>>
>> If that is not an issue, then we move forward and figure out how to
>> interop between similar autonomous grids.
>>
>> Charles
>>
>> From: Morgaine <morgaine.dinova@googlemail.com>
>> To: ogpx@ietf.org
>> Sent: Sunday, September 13, 2009 10:48:03 AM
>> Subject: Re: [ogpx] where does VWRAP fit?
>>
>> Charles, I too would be happy with any form of words that would allow us
>> to achieve the goal of interoperation between multiple distinct virtual
>> worlds that support our protocol.
>>
>> Unfortunately the current language precludes that, by overloading the term
>> "virtual world" to mean something different and blocking any reference to
>> multiple VWs.  Other problems abound too, such as not recognizing multiple
>> ToS, separate legal jurisdictions, etc --- a whole raft of problems arise
>> from the chosen "single virtual world" language.  That choice was made
>> wholly without benefit nor justification, and it has led to this problem
>> directly.
>>
>> If "the virtual world" in the OGP documents were replaced by "the
>> communicating parties" or "the participants" or "the participating
>> endpoints" or "the participating services" or "the participating regions" or
>> "the communicating regions" or just plain "the regions", or if a brand new
>> word were coined for "the regions controlled by the interacting ADs", then
>> we would be getting somewhere, because then we could discuss how to make
>> multiple VWs interoperate.
>>
>> Currently we cannot do that, because the documents refer to only one
>> single virtual world owing to the OGP legacy, and hence preclude us even
>> discussing multiple virtual worlds.  The problem is entirely an artifact of
>> the language chosen for the original OGP documents which only sought to grow
>> a single world.  It has no place in a multi-world VWRAP, as it brings no
>> benefits but introduces numerous problems.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ============================================
>>
>> On Sun, Sep 13, 2009 at 4:58 PM, Charles Krinke <cfk@pacbell.net> wrote:
>>
>> I agree with Morgaine here. The whole point of this group from my selfish
>> viewpoint is to enhance OGP to allow a more seamless interop between virtual
>> worlds such as SecondLife, OSGrid, ReactionGrid, ScienceSim and others.
>>
>> To the extent that we enable this ability, our Metaverse becomes more
>> diverse and robust.
>>
>> I am not interested in fretting over the wording of this or that document,
>> but what I am interested in is making sure that we are headed in the
>> direction of interoperability between independent virtual worlds such as the
>> four examples above. These are not the only examples, only the four that
>> appear to have significant diversity and robustness to be considered in a
>> list of virtual worlds for interop.
>>
>> With that in mind, I look forward to seeing more OGP interop with things
>> like the 'gridnauts' from the SecondLife Betagrid to IBM OpenSim standalone
>> regions and from the SecondLife Betagrid to OSGrid as was demonstrated a
>> year or so ago.
>>
>> Along the way, the HyperGrid notions will undoubtedly come into play.
>> These notions are also valid and are currently in use between various
>> OpenSim regions and OpenSim grids and as appropriate, the technical details
>> will be discussed as they evolve in a more or less consistent direction.
>>
>> Charles
>> From: Morgaine <morgaine.dinova@googlemail.com>
>> To: ogpx@ietf.org
>> Sent: Saturday, September 12, 2009 11:55:21 PM
>>
>> Subject: Re: [ogpx] where does VWRAP fit?
>>
>> Just in case it's not plain, this discussion is now post-charter agreement
>> I believe.  Ie. we're not revisiting the charter, at least for a while, and
>> hence the following is in the context of defining the problem space,
>> solution space, and draft protocol specifications. :-)
>>
>>
>> On Fri, Sep 11, 2009 at 5:15 PM, Joshua Bell <josh@lindenlab.com> wrote:
>>
>> And yet, from a formal/legal perspective, things are far more complicated
>> than this, which is why "countries" is a non-technical term and those
>> seeking to be precise use lovely terms like "nation-states". Check out
>> http://en.wikipedia.org/wiki/Nation for some discussion about the
>> terminology, or think about examples like England which is a country by yet
>> not a sovereign state; it is part of the United Kingdom of Great Britain and
>> Northern Ireland, which in turn is a sovereign member state of the European
>> Union (Hopefully I got that right...). Or think of microstates - contested
>> and otherwise. It's not our job as technology implementers and spec writers
>> to dictate policy, or disenfranchise the world-view of others.
>>
>> This is pushing the analogy too far, but I can run with it if you like.
>> ;-)
>>
>> First of all (excuse the use of Second Life here, but it is our primary
>> example), note that the operators of Second Life and all of the residents of
>> Second Life know exactly which virtual world they operate or inhabit.  There
>> is not the slightest shadow of doubt about this in anyone's mind, and
>> therefore the regular suggestions that "virtual world" is ambiguous or
>> undefined or uncertain are extremely ill-founded.  Likewise, exactly the
>> same is true of OSgrid, as another example.  The alleged uncertainty about
>> the meaning of "virtual world" does not exist in the context of OSgrid (nor
>> of the many other similar grids).  They know exactly who and what they are.
>>
>> Consequently, there cannot be any uncertainty about the meaning of
>> "virtual worlds" when we consider interop between two worlds such as Second
>> Life and OSgrid either.  There are two of them, each is a virtual world, and
>> they are distinct.  Linden Lab is not the only party that understands that
>> their virtual world has boundaries and policies that make it distinct and
>> separate from other virtual worlds.  All VW operators and all VW residents
>> understand this too, as perfectly as Linden Lab.  Claiming complexity or
>> complication in this is simply wrong.
>>
>> Nevertheless, I'll run with your idea of inner complication for you, just
>> to show that it is ill-founded for virtual worlds.  Let's consider the case
>> of inner political subdivisions within nation states, and let's examine the
>> analogy of such inner subdivisions with interop between regions as opposed
>> to interop between virtual worlds.
>>
>> Take for example the county of Sussex within the UK and the state of
>> Kansas within the US.  (These are arbitrary choices.)  Can a traveler from
>> Kansas visit Sussex by negociating a permit between the administrative
>> domains of Kansas and Sussex?  Clearly not.  The "interop" that needs to
>> occur is between the United states and the United Kingdom, even if a direct
>> flight is taken from Kansas to Sussex without a single foot being placed
>> outside of the boundaries of Kansas and Sussex.
>>
>> And this is exactly what happens between virtual worlds as well.  Assuming
>> for the sake of the example that policy allows interop between SL and
>> OSgrid, a region from SL and a region from OSgrid cannot interop without
>> their respective virtual worlds being involved, because it is those TWO
>> worlds that determine the policies under which the interop occurs, and it is
>> those TWO worlds that define the sets of VWRAP services that are involved.
>>
>> You can't cut one of those worlds out of the process, unless the idea is
>> to "steal" regions from it, which of course is not the case here.  That 2nd
>> virtual world must be involved if one of its regions is involved.
>>
>> Agreed. Just as the real world is not simply partitioned into "countries",
>> virtual places will express far more organizational variety than we can
>> currently imagine. I don't feel anointed to define terminology for the
>> future users of such technology.
>>
>> Unfortunately OGP did believe itself to be anointed enough to try to sweep
>> the identity of virtual worlds out of the equation altogether by defining a
>> "same virtual world" that bears no relationship whatsoever to any "virtual
>> world" known to any operator or resident anywhere. ;-)  I am hoping that we
>> can dispense with that totally incongruous redefinition of a well understood
>> term in the VWRAP specifications as easily as we eradicated it from the
>> charter. :-)
>>
>>
>> Having removed it, we can then address how VWRAP implements the
>> user-oriented requirement of interop between multiple virtual worlds, since
>> removing the "single VW" will allow us to refer to more than one VW.  We've
>> already been told authoritatively that, as it stands, the protocol will only
>> connect single regions or a region domain of regions to one single virtual
>> world, and not interop with a whole other VW.
>>
>> There is no such authority that could make such a statement. The draft
>> charter does not speak in a normative fashion about virtual worlds,
>> precisely to avoid such claims - based on your feedback!
>>
>> By "authoritatively", I was referring to the statement made by Meadhbh
>> Siobhan on 30 August to the effect that "OGPX is intended to provide
>> interoperability, not between worlds, but between hosts that work together
>> to simulate a virtual world", which I assume was authoritative.  The virtual
>> world being simulated is the point of contention here.  The term either
>> introduces a new single virtual world that did not previously exist and
>> which bears no relationship to any virtual world known to any operator or
>> resident, or else it refers to just one, previously existing and well known
>> virtual world to which an independent region or region domain is being
>> added.
>>
>> What it CANNOT do is to provide interop between two well known VWs, simply
>> because it is not naming them nor specifying any interaction between them.
>>  An interaction between two region hosts does not provide interaction
>> between the two virtual worlds of which they are part --- it is at the wrong
>> level of the "virtual world stack", to make an analogy with layered
>> protocols.
>>
>>
>> VWRAP as a protocol suite should provide the framework for moving agents
>> between regions. Regions are represented as sets of services, which can be
>> provided by multiple service providers, and within multiple trust domains.
>>
>> Given that, if you personally define "virtual world" as a set of regions
>> that are provided by a single service provider, then VWRAP should indeed
>> provide the framework for agents to traverse those multiple virtual worlds,
>> policy permitting.
>>
>>
>> Except that such a redefinition of "virtual world" does not match the well
>> known meaning of the term in common use today.  I assume that you know what
>> "virtual world" means, since you operate the virtual world of SL, and that's
>> the common meaning that should be used here because it's the same meaning
>> that everyone else uses as well.
>>
>> You cannot just arbitrarily redefine a common term like that when creating
>> a protocol designed to work in an area that already has a meaning for that
>> term.  It sows total confusion among those who have been working in virtual
>> worlds for years, people who already know very precisely what "virtual
>> world" means, as I assume you do yourselves in the context of SL.  And with
>> reference to Kari's thread, such a redefinition makes it impossible to
>> address the most significant entities of interest from the perspective of
>> users, which are the distinct virtual worlds themselves.
>>
>>
>> If you personally define "virtual world" as the set of all regions that an
>> agent can visit (provided by one or more providers), then no, VWRAP would
>> not allow traversing multiple worlds because, by that definition, that agent
>> can only experience one such world.
>>
>> Multiple worlds exist.  Defining virtual worlds by reachability is
>> completely inappropriate --- they don't go away just because you can't reach
>> them.
>>
>> And that's the problem with the approach taken by the old OGP documents
>> --- they sought to define a single virtual world by reachability, instead of
>> accepting that multiple distinct virtual worlds exist but wish to
>> interoperate.  The language that was used precluded this most clear and
>> obvious interop semantic from even being addressed.  It overloaded the
>> crystal clear term "virtual world" with an abstract and highly manufactured
>> fiction that does not represent any virtual world that actually exists.
>>  (Don't say that it's not crystal clear --- you operate a virtual world and
>> you know what it is very clearly, as does everyone else.)
>>
>>
>> Again, the draft charter text explicitly avoids talking about social
>> constructs like "virtual worlds" precisely for this reason, based on
>> feedback from you and others.
>>
>>
>> The reason why agreement on the charter was reached relatively quickly was
>> because "virtual world" was almost completely withdrawn from the language
>> used in the charter.  In contrast, that task still lies ahead of us for the
>> next phase where we examine the problem space and draft specifications.
>>  Most importantly, the latest draft of the charter refers to "the state of
>>  a virtual  world", which strongly suggests that there are many virtual
>> worlds, and this was key to making the language of the charter satisfactory.
>>
>> However, the name of the protocol is now "Virtual World Region Agent
>> Protocol", which alludes to Meadhbh's statement that the interop being
>> considered is not between virtual worlds --- it's within a single virtual
>> world as defined by its agent domain.  The regions involved are all part of
>> that single virtual world, not parts of different virtual worlds since no
>> second AD is involved.  This is fine as long as the protocol is indeed not
>> intended for cross-VW interop, but we've been down that road before and
>> apparently there is still a desire to handle multiple VWs as well.
>>
>> Well that's fine, but we can't handle multiple VWs without referring to
>> them, and we can't refer to them currently because the term "virtual world"
>> is blocked from having a plural form by a very curious and wholly
>> unjustified redefinition of the term inside the specifications.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>>
>>
>> ================================================
>>
>> On Fri, Sep 11, 2009 at 5:15 PM, Joshua Bell <josh@lindenlab.com> wrote:
>> On Fri, Sep 11, 2009 at 12:36 AM, Morgaine <
>> morgaine.dinova@googlemail.com> wrote:
>> Users of virtual worlds know exactly what the term means, in the same way
>> that they can distinguish one country from another when they go on holiday.
>>  People have been living with the concept of different places ever since
>> they started travelling beyond their village boundary, and nowadays the
>> popularity of tourism embodies that concept most vividly in the form of
>> countries.  Different countries tend to look different and have different
>> cultures and different rules (local policies).  This is entirely natural and
>> instinctive to us.
>>
>> And yet, from a formal/legal perspective, things are far more complicated
>> than this, which is why "countries" is a non-technical term and those
>> seeking to be precise use lovely terms like "nation-states". Check out
>> http://en.wikipedia.org/wiki/Nation for some discussion about the
>> terminology, or think about examples like England which is a country by yet
>> not a sovereign state; it is part of the United Kingdom of Great Britain and
>> Northern Ireland, which in turn is a sovereign member state of the European
>> Union (Hopefully I got that right...). Or think of microstates - contested
>> and otherwise. It's not our job as technology implementers and spec writers
>> to dictate policy, or disenfranchise the world-view of others.
>>
>> That concept doesn't disappear when "places" become digital.  Instead the
>> concept blossoms, because without the constraints of the physical world,
>> virtual places can be so dramatically different.
>>
>> Agreed. Just as the real world is not simply partitioned into "countries",
>> virtual places will express far more organizational variety than we can
>> currently imagine. I don't feel anointed to define terminology for the
>> future users of such technology.
>>
>> Having removed it, we can then address how VWRAP implements the
>> user-oriented requirement of interop between multiple virtual worlds, since
>> removing the "single VW" will allow us to refer to more than one VW.  We've
>> already been told authoritatively that, as it stands, the protocol will only
>> connect single regions or a region domain of regions to one single virtual
>> world, and not interop with a whole other VW.
>>
>> There is no such authority that could make such a statement. The draft
>> charter does not speak in a normative fashion about virtual worlds,
>> precisely to avoid such claims - based on your feedback!
>>
>> VWRAP as a protocol suite should provide the framework for moving agents
>> between regions. Regions are represented as sets of services, which can be
>> provided by multiple service providers, and within multiple trust domains.
>>
>> Given that, if you personally define "virtual world" as a set of regions
>> that are provided by a single service provider, then VWRAP should indeed
>> provide the framework for agents to traverse those multiple virtual worlds,
>> policy permitting.
>>
>> If you personally define "virtual world" as the set of all regions that an
>> agent can visit (provided by one or more providers), then no, VWRAP would
>> not allow traversing multiple worlds because, by that definition, that agent
>> can only experience one such world.
>>
>> Again, the draft charter text explicitly avoids talking about social
>> constructs like "virtual worlds" precisely for this reason, based on
>> feedback from you and others.
>>
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>