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 > >
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Kari Lippert
- [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Meadhbh Siobhan
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 David W Levine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 David W Levine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 SM
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- [ogpx] Policy between services David W Levine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 SM
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood