Re: [ogpx] (no subject)

[Vaughn Deluca <[e-mail]>]

I realise now I have been confused about the meaning of the Region Domain,
but your post clears up a lot for me.
Some of this has been voiced by others already, but here is my personal
view.

I think the notion of RD is very useful as a tool to specify *common* policy
for some regions.
Looking at the TP draft, its absolutely clear that the region is the
endpoint, and a rez cap will also point to the region. Yet, as you already
mentioned *behind* that interface, the region can get some of its policy
from a region domain "service".  Viewed like this the RD becomes a lookup
service for information that otherwise has to be duplicated in possibly a
lot if regions. The RD is not a *front*end containing the regions, but its a
*back* end service *used* by the regions, and the fact that some regions do
use this particular service places them de-facto *in* a that RD.

Since policy it outside the protocol, it is not  needed to specify how the
regions consults the RD policy "service". All of that interaction is hidden
behind the interface to the region, and it is up to the deployer of the
region to decide how to deal with this problem. However, if somebody feels
the need,  I have no objection to formalising the interaction in  *optional*
protocol steps, that the region can take to help it making policy decisions.

-Vaughn

On Tue, Oct 6, 2009 at 11:45 PM, David W Levine <[e-mail]> wrote:

>
> From this mornings AWGroupies discussion, I want to try and pin down
> some terminology:
>
> I've been saying "Policy happens at services." I think I need to make
> this more precise, so:
>
> The current model grounds out in Web Services and streams of "events"
> (Notionally delivered in UDP or over an event queue in the current
> discussions) So.. From the bottom up:
>
> Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, or
> JSON) which defines a web service capability A set of "events" which
> are notionally short, asynchronous and delivered quickly.. (How much,
> content flows in this form is at yet unclear)
>
> Web service endpoints cluster into set of services, which describe the
> bulk of the functionality in the specifications. (Loosely, this tends
> to be the Authentication Services, Region Service, Inventory services,
> Asset Services and IM services) There is nothing in this model which
> dictates how to implement or deploy these services behind the defined
> interfaces
>
> Laid over this lose description we have had the notion of "domains" in
> particular, the Agent and Region domains. The current (somewhat
> backlevel) intro document says:
>
>    The Open Grid Protocol assumes a division between systems offering
>    user / avatar oriented services and systems offering virtual world
>    simulation services.  OGP was designed to support the case where the
>    administrative authority for agent services is distinct from the
>    authority providing simulation and object persistence services.  The
>    administrative authority of the former group is termed the "agent
>    domain" while the latter is termed the "region domain."  The protocol
>    allows the agent domain and region domain to be distinct; in other
>    words, a user's identity may be managed by one person or organization
>    while the virtual world they inhabit may be simulated by hosts owned
>    by a completely different organization.
>
> Over the past few weeks, there has been a lot of discussion about the
> possible deployment patterns people will support, and the last
> definition of the split I have seen on the lists seems to be
>
> that if it holds the Authentication and Agent ID services its an agent
> domain, and if it holds the Virtual Presence services its a region
> domain. This seems quite reasonable.
>
> There is also the notion, that domains represent administrative
> spans of control, and that services within a domain share policy.
>
> At the same time.. actual policy is mediated by service end
> points. This is to say the moment we can actually apply policy is
> when a remote service requests a capability, or invokes a capability
> or (possibly) delivers an event or message to us on an asynchronous
> connection.
>
> I see two or possibly three bits of confusion here. I'm going to start
> with the basic one, which has come up over the past week.
>
> People keep saying "Region Domain Decides" or "Agent Domain Decides"
> or "The service consults the Agent Domain" I think this muddies stuff
> because it promotes the domain to an active element, when the real
> behavior is "A service endpoint is called, possibly with some special
> tokens,
> possibly, with a negotiation ensuing and the service endpoint acts
> according to its policy."
>
> Now, the service endpoint may well reside inside an administrative
> domain, and may have its policy dictated by its deployer. But without
> an active element, I don't think the domain "participates"
>
> The second thing which concerns me is that we're sort of conflating
> two useful ideas here. One, the split between authenticator and
> holders of agents, and virtual spaces, and the other, a pattern of
> common use in deploying services. I think this becomes increasingly
> strained, as you look at regions interacting with multiple services,
> and with services which fall outside of the agent/region split, and
> yet belong to one or more administrative domains.
>
> So.. I am not suggesting we throw away these concepts, I am suggesting
> that we look carefully at how we are tossing the word around, whether
> we are overloading it, and whether we could better serve our
> developing a shared understanding by being more rigorous, and more
> careful about how we attack some of these concepts
>
> - David Levine
> ~ Zha Ewry
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>