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

Vaughn Deluca <vaughn.deluca@gmail.com> Fri, 02 October 2009 01:46 UTC

Return-Path: <vaughn.deluca@gmail.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 26F7B3A6819 for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 18:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.787
X-Spam-Level:
X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, 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 UKrHzJvq2w+z for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 18:45:57 -0700 (PDT)
Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 31BE23A680C for <ogpx@ietf.org>; Thu, 1 Oct 2009 18:45:56 -0700 (PDT)
Received: by fxm28 with SMTP id 28so623067fxm.42 for <ogpx@ietf.org>; Thu, 01 Oct 2009 18:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TeeY1QCS7RWBGrv1Obk7VIsFQbS8stNWnQaS6pCox28=; b=O/xT3/q7B3hgDzoATUlYHqJVxAsldQCeRddE8WDEhdyqmLxsRotGLxi3jOuMJ7+RET POX5/ZOUg4Jf6mj5t/KPJFh8CM3P8ZJb9rq+SjENmAXRdPJh0A8Qm1irXI2VI3Lic7t8 KZaSe/ofaz56Emu24XDO7aiLvb/XBDDvrpLyU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F4YwghhrH74db7+KAmDd6CjhLiBedB9/G+gaX+RGYvFapOk4vNBfXRby+jHgXWzvLI 2GDa0bAR1FbLXjzHF+2mmffgJcNlhwij0/f+K/zxZ4bH6wleuFzvTBZiqKZzCqWwDKkW Abr/f/51fodzGqfB/OafOIU2mT6UOKWMMt76U=
MIME-Version: 1.0
Received: by 10.204.48.203 with SMTP id s11mr606129bkf.133.1254448034883; Thu, 01 Oct 2009 18:47:14 -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: Fri, 02 Oct 2009 03:47:14 +0200
Message-ID: <9b8a8de40910011847n61be601ej6a4f10a64195ef0@mail.gmail.com>
From: Vaughn Deluca <vaughn.deluca@gmail.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Content-Type: multipart/alternative; boundary="00032555877682296b0474e9f19b"
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: Fri, 02 Oct 2009 01:46:00 -0000

@ Joshua & Carlo, You have beaten me to the punch, i write to slow...
@ Morgaine, since its written  i might as well post my response, it broadly
agree's with what has been said already :) convergence indeed!


[...]
>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.

No, it does not have to be that complicated, for the *teleport* (and
ignoring assets for now) of an agent from AD1 (present in RD1) to RD2 the
only interaction needed is between AD1 and RD2.
So for sure AD1 caries RD related policy, but *only* in respect to allowing
the TP  to RD2.  On the destinations world's end, AD2 has for this TP no
role at all,  AD1 does not need to talk to AD2, all policy can be in RD2.

However, maybe its *technically*  more convenient to derive all policy for
RD2 from AD2, and make RD2 a straw man for AD2 as far as policy is
concerned. As long as AD2 and RD2 fully trust each other it makes no
difference, it would under full trust even be possible to cut RD2 completely
out of the loop regarding policy aspects, and have AD1 and AD2 work out the
intended TP to RD2.  Its up to the owner of RD2 to decide if she wants to do
it that way, and simply trust an external AD2, or be more careful and run
her own AD2 allowing her to keep full control over who is going to be
allowed into RD2.

So yes, in this case destination largely determines policy, but not
exclusively, AD1 has to agree to let the agent go. If destination policy  is
defined by RD2 alone, or by a combination AD2/RD2 or even by AD2 alone is
not really important.
I think that *protocol efficiency* should be used as  guideline to determine
that. In terms of freedom it does not matter, since its always possible to
run your own AD services if you feel you can't trust somebody else his
service.


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

I would view that example as a special case were AD1 has a full trust policy
regarding were it allows its residents to travel to, in combination with a
version of VWRAP were the trust issues for a RD are all handled by the RD
itself, rather than delegating the trust issues to a trusted AD.


>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. :-)

I *think* Infinity had something like what i described above in mind, but
she can speak for herself.

Anyhow I have the feeling that there is a very high level of basic agreement
in this group. But Zha's remark about the danger of creating a system were
everybody complies, yet hardly any interop is possible is highly relevant.
This "Balkanisation" has been mentioned before, but i do not see a principle
way to prevent it. In the end it will be the trust networks that determine
what happens in terms of interop, and users will probably vote with their
feet.

The next step are the assets services. That is slightly more tricky, but in
principle not different from the TP case. Here AS1 has policies about
letting stuff go, so clearly its *not* only "DDP" in this phase. Yet, RD2
(or its ruling AD2 if we prefer that format) does have a voice, and might
not want to accept objects from an AS (or optionally its ruling AD/RD) if
that service has griefer associations.

-Vaughn

On Fri, Oct 2, 2009 at 1:13 AM, Morgaine <morgaine.dinova@googlemail.com>wrote:

> On Thu, Oct 1, 2009 at 10:57 PM, Joshua Bell <josh@lindenlab.com> wrote:
>
>>
>> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com>wrote:
>>
>>>
>>> Your next step is to realize that, for two structurally identical worlds,
>>> if the seat of policy of one lies in its AD, then the seat of policy of the
>>> other also lies in its AD.  Therefore your statement needs to be modified to
>>> the following:
>>>
>>> IMHO, it should be apparent that both the AD of the source world and the
>>> RD and AD of the destination world all need to make policy decisions.
>>>
>>>
>> I don't agree with this at all.
>>
>> A VW service provider could operate a region domain with no agent domain.
>> I believe this is VERY LOOSELY equivalent to running an OpenSim instance in
>> Grid mode today (but I can't state that definitively) the person running the
>> sim is basically running just the region, and relying on someone else's
>> agent domain (agent-centric services).
>>
>> Similarly, BigGiantCo could operate an agent domain for their employs (as
>> a bolt-on to their enterprise LDAP server, say) with no region domain.
>>
>> A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to
>> place the agent in a region. There aren't necessarily any other RDs or ADs
>> involved at all. This is where protocol and policy come into play - the AD
>> needs to communicate with and trust the RD and vice versa (even if that's
>> nil-trust).
>>
>
>
>
> Those are valid examples, but they're cherry picked to support your
> specific use case.
>
> 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.
>
> 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.
>
> 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.
>
> 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. :-)
>
>
> Morgaine.
>
>
>
>
>
>
> ======================================
>
> On Thu, Oct 1, 2009 at 10:57 PM, Joshua Bell <josh@lindenlab.com> wrote:
>
>>
>> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com>wrote:
>>
>>>
>>> Your next step is to realize that, for two structurally identical worlds,
>>> if the seat of policy of one lies in its AD, then the seat of policy of the
>>> other also lies in its AD.  Therefore your statement needs to be modified to
>>> the following:
>>>
>>> IMHO, it should be apparent that both the AD of the source world and the
>>> RD and AD of the destination world all need to make policy decisions.
>>>
>>>
>> I don't agree with this at all.
>>
>> A VW service provider could operate a region domain with no agent domain.
>> I believe this is VERY LOOSELY equivalent to running an OpenSim instance in
>> Grid mode today (but I can't state that definitively) the person running the
>> sim is basically running just the region, and relying on someone else's
>> agent domain (agent-centric services).
>>
>> Similarly, BigGiantCo could operate an agent domain for their employs (as
>> a bolt-on to their enterprise LDAP server, say) with no region domain.
>>
>> A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to
>> place the agent in a region. There aren't necessarily any other RDs or ADs
>> involved at all. This is where protocol and policy come into play - the AD
>> needs to communicate with and trust the RD and vice versa (even if that's
>> nil-trust).
>>
>>
>> _______________________________________________
>> 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
>
>