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

[Morgaine <[e-mail]>]

IMO, this post of David's is one of the most important ones in the thread,
in particular its opening paragraph:

On Thu, Oct 1, 2009 at 11:25 PM, David W Levine <[e-mail]> wrote:

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


It's important firstly because it provides us with a clear path towards
implementation, and it seeks to reduce the focus on "domains" that has
caused so much trouble --- services are so much easier to understand and to
implement and to discuss.

And it's important secondly because it underlines the massive and overriding
power of the Agent Domain, because an AD provides caps that give access to
services, and therefore it has more power in dictating policy than any
service to which it gives access.  This places a mammoth constraint upon
David's first statement that "services are going to manage policy", because
there will be no access to those services *at all* unless an AD allows it.

(It's also worth pointing out that the AD's power to provide caps is in
direct conflict with the 2nd part of David's sentence (highlighted):  "services
are going to manage policy, *not the domains they reside in*".  The AD
clearly is managing policy, *in a major way*, by providing caps that allow
access to services.)

Fortunately, the way out of this dilemma has already been provided by
Joshua, namely limiting the scope of the AD to agent-related services only,
while RDs control region-related services thus allowing DDP, in much the way
that Carlo desired many weeks ago. :-)

If ADs are limited to agent-only services such as authentication, then there
are no significant problems.  For example, if ADs provides only
authentication, then AD2 doesn't need to be consulted when agent A1
teleports from RD1 to RD2, since A1 is already authenticated with AD1 and
additional authentication with AD2 is not required.

However, if ADs also provide caps to region-related services such as Asset
Services, then AD2 will need to be consulted when agent A1 teleports to RD2,
otherwise A1 won't have access to the assets of W2 that happen to reside in
RD2.

The following paragraph is crucial and its impact needs to be understood.

If ADs are allowed to provide caps to asset services *in any deployment
pattern whatsoever*, then AD2 will *always* have to be consulted if it
exists, *in all deployments*, because W1 does not know what kind of
deployment pattern is used by W2.  This affects our protocol very strongly
--- looking for an AD2 and querying it if it exists will not be optional.

Clearly we have some thinking to do about what is allowed in ADs if we wish
to avoid this.

Finally, I want to quote a sentence from David's 2nd paragraph, which I
think is quite illuminating:



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



I agree entirely.  The rather coarse AD/RD split worked OK in its original
scope as an implementation mechanism for adding regions to an existing
world, but it's not very helpful now that we have started examining what
really needs to happen for interop in multi-world deployments.

If we feel a need for additional domains, let's add them --- for example, a
separate Storage Domain might be helpful to ensure that AD2 never need to be
consulted (unfortunately Asset Domain provides a conflicting abbreviation).
And if we feel the need to abandon the concept of domains entirely and just
leave services, then let's do that too.  After all, the domain model was
meant to help, not hinder.  Our work is concerned primarily with defining a
protocol --- domains are optional!  :-)


Morgaine.





=======================================

On Thu, Oct 1, 2009 at 11:25 PM, David W Levine <[e-mail]> wrote:

>
> 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 <[e-mail]>*
> Sent by: [e-mail]
>
> 10/01/2009 05:57 PM
>   To
> [e-mail]  cc
>   Subject
> Re: [ogpx] VWRAP Draft Charter - 2009 09 01
>
>
>
>
>
> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <*[e-mail]*<[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
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>