Re: [ogpx] (no subject)

[Kari Lippert <[e-mail]>]

 Any service request, invocation, message delivery, or other type of
communication attempt with either an AD or an RD will likely require
the presentation of some sort of credential. Policy is outside the
protocol as it is an implementation detail, but the protocol needs to
indicate what would be (minimal) credentials. Clearly we need more
than a notional idea of what that information entails. The policies
that determine how (or even if) the domain uses that information is
clearly up to the domain implementation and beyond the scope of the
protocol.

While we need to consider the types of things the domains might do so
that the protocol supports the transmittal of the appropriate
information, we are only specifying a format for communicating
information between the domains.  Unless I've missed some critical
point somewhere, I believe we can largely treat the domains as black
boxes and not worry their implementation or how they will use the
information they receive. We only need to understand what information
a domain would require to accept or react to a communication. True?



Kari



On Sun, Oct 11, 2009 at 6:55 PM, Vaughn Deluca <[e-mail]> wrote:
> 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
>>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>