Re: [ogpx] VWRAP Draft Charter

One.. I think its very important to keep in mind that services are going 
to manage policy, not the domains they reside in. This is important, 
because it highlights the fact that what's going to happen when different 
people deploy this stuff in different deployments is going to vary.  I 
think we need to be very careful to focus not on any one deployment 
pattern, but the broader set of possible deployment patterns we are 
attempting to enable. This goes hand in glove with Joshua's comments 
below. 

This leads to 

Two.. I *think* the correct model is "All the services involved may have 
policies they bring to the table."  The set of actions which are possible 
between an arbitrary service inside of one deployment and an arbitrary 
service inside another is going to be
dictated by the policies those two services follow.  This is especially 
likely when looking at things like asset permissions.  Consider the case 
of a region attempting to pass a prim to an asset store for storage. The 
Region may have policies about which
asset stores it is willing to deliver assets to. The Asset store may have 
policies about which regions it is willing to accept assets from. If the 
user's agent domain holds his inventory (One, but not the only possible 
deployment pattern) it may have policies about
the asset servers it interacts with. Its possible to imagine cases where 
the only role the ADs play in this policy decision is that they have 
authenticated the user, 

We need to be careful, when looking at this stuff to strike a balance 
between focusing on the current deployed clusterings, and turning 
everything into soup. That said, the actual deployed systems which 
implement these specifications are only going to be able
to enforce policy at the interfaces we define, and these interfaces are on 
services, not domains.  In fact, as I've argued several times, I think, in 
general, the notion of a domain emerges from the policies of the deployed 
services, not the other way around. Infinity's made a very nice case for 
describing the key distinctions as being "Agent domains include the auth 
service" and "Region Domains include the presence service"  If we keep 
this in mind, I think it helps us move away from thinking purely in terms 
of the split that Linden Labs has focused on. To circle back to the 
question of soup, simply focusing on the services risks describing stuff 
that's falls into the HLA/DIS trap of having deployments which are each 
"conforming" but vary so much in assumption as to not actually 
interoperate. 

- David
~Zha

Joshua Bell <josh@lindenlab.com> 
Sent by: ogpx-bounces@ietf.org
10/01/2009 05:57 PM

To
ogpx@ietf.org
cc

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

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