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

[Morgaine <[e-mail]>]

On Thu, Oct 1, 2009 at 10:57 PM, Joshua Bell <[e-mail]> wrote:

>
> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <[e-mail]>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 <[e-mail]> wrote:

>
> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <[e-mail]>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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>