[ogpx] (no subject)

David W Levine <dwl@us.ibm.com> Tue, 06 October 2009 21:43 UTC

Return-Path: <dwl@us.ibm.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E993A6A10; Tue, 6 Oct 2009 14:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.98
X-Spam-Level:
X-Spam-Status: No, score=-4.98 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t3rFagqgrZD; Tue, 6 Oct 2009 14:43:40 -0700 (PDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id C41EA3A69BD; Tue, 6 Oct 2009 14:43:39 -0700 (PDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n96Lc8gK025580; Tue, 6 Oct 2009 17:38:08 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n96LjAMj242794; Tue, 6 Oct 2009 17:45:10 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n96LjAJd015764; Tue, 6 Oct 2009 17:45:10 -0400
Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n96LjAIB015753; Tue, 6 Oct 2009 17:45:10 -0400
In-Reply-To: <f72742de0910061306u5535232fx8a1d05cb2330bce1@mail.gmail.com>
References: <e0b04bba0910050530x6e85e4e9va71dabab678af23b@mail.gmail.com> <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <e0b04bba0910060929m6f218e8bw39a0b09dc58f8e75@mail.gmail.com> <f72742de0910061032n486601e9y99b15fd619da9831@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> <f72742de0910061306u5535232fx8a1d05cb2330bce1@mail.gmail.com>
To: Joshua Bell <josh@lindenlab.com>
MIME-Version: 1.0
X-KeepSent: C69C61CF:F2BCE649-85257647:00774F20; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <OFC69C61CF.F2BCE649-ON85257647.00774F20-85257647.00777DDF@us.ibm.com>
From: David W Levine <dwl@us.ibm.com>
Date: Tue, 6 Oct 2009 17:45:09 -0400
X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/06/2009 17:45:09, Serialize complete at 10/06/2009 17:45:09
Content-Type: multipart/alternative; boundary="=_alternative 00777DDC85257647_="
Cc: ogpx-bounces@ietf.org, "ogpx@ietf.org" <ogpx@ietf.org>
Subject: [ogpx] (no subject)
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2009 21:43:42 -0000

>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