Re: [ogpx] (no subject)

[Vaughn Deluca <[e-mail]>]

Kari,

I think we should treat AD and RD separately, since they are not completely
similar in the way they are currently used. For now I like to stick to the
region domain. You wrote:

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

Yes, absolutely, in any case as far as the region domain is concerned. That
domain is only an instruments of policy and administration, and as such IMHO
completely out of scope of the protocol, so not only can we can treat it as
a black box, we could even completely forget about it in protocol terms, and
leave it up to the administrators to use it in whatever way they like,
behind the endpoints of the protocol.  That said, I *do* think the region
domain is a useful administrative concept, and an efficient way to implement
policy.  Given that fact, a case can be made that we should specify
something, if only to make clear how we view the concept can be used
effectively. I have no real desire to do so, but if we go that way, you re
right:

>We only need to understand what information a domain would require to
accept or >react to a communication. True?

Yes, i think so. Infinity gave 3 common ways to determine policy at the
bottom of this post:
http://www.ietf.org/mail-archive/web/ogpx/current/msg00541.html

>a. identity implies policy.
>b. authenticator implies policy.
>c. region metadata implies policy.

For the Region domain <-> Region service interaction,  option a. will work
perfectly. Since by definition all involved hosts are under the same
administration, the identity of the hosts (is indicated by host name or IP
address) is all that is needed to tell the domain it can trust the region
service. The content of the message exchange does not concern us. But if we
wished we could provide some examples along the lines Magnus and Infinity
suggested here:
http://www.ietf.org/mail-archive/web/ogpx/current/msg00492.html
where  they were discussing solutions for policy exchange between Agent
Domain and Region Service. I like the third case, were the interaction
follows the REST style.

-Vaughn

On Mon, Oct 12, 2009 at 1:30 AM, Kari Lippert <[e-mail]>wrote;wrote:

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