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

Joshua Bell <josh@lindenlab.com> Thu, 01 October 2009 23:30 UTC

Return-Path: <josh@lindenlab.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 4B7403A68F9 for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 16:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 u+WFnHXdsRHA for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 16:30:48 -0700 (PDT)
Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id AC9E03A6781 for <ogpx@ietf.org>; Thu, 1 Oct 2009 16:30:48 -0700 (PDT)
Received: by pzk35 with SMTP id 35so927977pzk.29 for <ogpx@ietf.org>; Thu, 01 Oct 2009 16:32:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.192.18 with SMTP id p18mr722950rvf.168.1254439931826; Thu, 01 Oct 2009 16:32:11 -0700 (PDT)
In-Reply-To: <e0b04bba0910011613w6f25b684w1b0f2e8c7187b3de@mail.gmail.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <e0b04bba0909132243r10730a3fq275f8143087807c6@mail.gmail.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <e0b04bba0909291751g157d2043g1c15e8d8ac417ccf@mail.gmail.com> <f72742de0909300910t23131532i1719d2c86423fa41@mail.gmail.com> <e0b04bba0910011434i13f890bfodd22cd15eef17697@mail.gmail.com> <f72742de0910011457o5e757135rd9db7fc7f4a1389@mail.gmail.com> <e0b04bba0910011613w6f25b684w1b0f2e8c7187b3de@mail.gmail.com>
Date: Thu, 01 Oct 2009 16:32:11 -0700
Message-ID: <f72742de0910011632n3488ff6aqbf93edbda2a51637@mail.gmail.com>
From: Joshua Bell <josh@lindenlab.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary="000e0cd153e68753ec0474e80e24"
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: Thu, 01 Oct 2009 23:30:50 -0000

I think we're converging...

On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinova@googlemail.com>wrote:

>
> Those are valid examples, but they're cherry picked to support your
> specific use case.
>
>
Well, simplified examples. I don't believe more complicated examples
actually add meaningfully at a protocol level, as will become clear...


> Please examine the more general use case of two complete SL-like worlds
> using VWRAP, W1 and W2.  They both have ADs and RDs, so let's label those
> with 1's and 2's accordingly.
>

At a protocol level, I don't think VWs exist. There are services, which
we're clustering into AD and RD. Although we may later determine there are
further subdivisions, that's our working model in the drafts. Further drafts
are strongly encouraged!


> If both ADs and RDs determine policy together (as you stated), then you
> can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy
> coming into play, otherwise you would be subverting AD2's policy.
>

Here's the crux of the issue: in our model, the provider of W2 is offering
two sets of services, AD2 and RD2. There may be a policy covering W2 in
general, which would affect the AD2 and RD2 services. However, if an agent
"from" W1, meaning the agent services are provided by AD1, attempts to visit
RD2, then AD2 does *not* come into play. The protocol describes the
negotiation between the client, AD1 and RD2 *only*.

(Again, this is insofar as the model in the current drafts are concerned. If
we're missing something, please bring the conversation back to the drafts
and point out issues and/or submit new work for discussion!)

Let me restate: even if AD2 and RD2 are governed by the same policy -
potentially even to the point of being implemented by the same monolithic
piece of code! - AD2 is irrelevant *from a protocol perspective* in the
attempt to place an agent from AD1 into AD2, since by definition the AD2 and
RD2 services are disjoint.


> There *IS* one way of allowing the above, and that is to require that ADs
> carry no region-related policies at all, so that consulting only the
> destination RD is sufficient.  This would give us a perfect *Destination
> Determines Policy* (DDP) system.  The W1 resident could then TP from RD1
> to RD2 without consulting AD2 at all.
>

.... and so it looks like we're in agreement - if this wasn't clear, then we
need to review the drafts (please, go for it!); it should be the case that
ADs carry policies about region services... except, of course, that the AD
may say "hey, you can't go to *that* RD...".

I believe I may have misread some of your earlier posts as implying that the
agent's AD was not allowed to have a say in policy decisions, only the
destination RD. I have a clearer reading of your DDP statement, though, that
of course it's the AD reasoning about the RD, and contrariwise the RD
reasoning about the AD. If we call that "DDP" then we're copacetic.



> If you wish to define ADs in this way then we are in perfect agreement,
> since DDP is essential for interop between worlds.  I am hoping that this is
> what you had in mind for when we start discussing specific AD and RD
> policies. :-)
>