[ogpx] verbiage : domain, agent domain, region domain, trust domain, service, etc.

Meadhbh Hamrick <ohmeadhbh@gmail.com> Mon, 29 March 2010 17:16 UTC

Return-Path: <ohmeadhbh@gmail.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 636BF3A6AFB for <ogpx@core3.amsl.com>; Mon, 29 Mar 2010 10:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.121
X-Spam-Level: *
X-Spam-Status: No, score=1.121 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 Kur3UOr9-puw for <ogpx@core3.amsl.com>; Mon, 29 Mar 2010 10:16:54 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 309273A6AEB for <ogpx@ietf.org>; Mon, 29 Mar 2010 10:16:13 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 9so318757qwb.31 for <ogpx@ietf.org>; Mon, 29 Mar 2010 10:16:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type; bh=HrAuWIDuM6ql2IUnEtjrnLPhZQW+9ZO/QCvhLTfEX1Y=; b=cH0gZlOcPzBvZv3U0ibxIZ7y8zsmuM+3dEOuGinHLg10v55bWujA6QWTh4FgQHPSn3 bORS+N968DhbCD5QZBVh0f93WzcQP5B8+ctqWBudFA38cwEO+xPHIQKX/CkY5XvThmtD Wpt2RZhhSncHSweJqcoKseT9Zer9DIwjbkobs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=qZTrsMEy2SfiQrP1zZycNErLZUcMDRjOhrNyK59XAol8GUiIc+XrllS21yWhji33PU rTg0zXGv2443yb7+JXwthlgZEUcgYPUt4MXZLqnWHYrsiQs8kIyAjhcp6pxbU3oaKDuw iRYl4kGPTfWzj7Y+RBnlix4araLgvYqq9W73g=
MIME-Version: 1.0
Received: by 10.229.20.209 with HTTP; Mon, 29 Mar 2010 10:16:18 -0700 (PDT)
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
Date: Mon, 29 Mar 2010 10:16:18 -0700
Received: by 10.229.14.157 with SMTP id g29mr2820190qca.57.1269882998296; Mon, 29 Mar 2010 10:16:38 -0700 (PDT)
Message-ID: <b325928b1003291016i5c07e6d9na0feda9faf930aeb@mail.gmail.com>
To: ogpx <ogpx@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [ogpx] verbiage : domain, agent domain, region domain, trust domain, service, etc.
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <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: Mon, 29 Mar 2010 17:16:55 -0000

so... there's been some grumbling about the use of terminology on the
list and in drafts. at the f2f we reiterated the need to agree on some
basic terms. as i'm sure we all have one or two things to say about
this subject, let's get the ball rolling...

as many people on this list know, the terms "agent domain" and "region
domain" come from the previous OGP work. the term "domain" was
originally thought to mean "a collection of machines administered by
the same authority." an "agent domain" was a domain that managed
user-oriented data: profile info, avatar presence, IM services,
inventory, etc. a "region domain" was a domain that managed
place-oriented data and processes: object presence, simulation, etc.

as the model was developed and we gained more deployment expertise, a
couple things became clear:

1. there's a high quality implementation of an asset service out there
(cable beach) which _could_ be deployed independently of an OpenSim or
LL instance. does this mean we should have an "asset domain"?

2. linden deployment patterns (which formed the basis of early drafts)
may not be used by all participants. specifically, an agent domain may
"contract out" fulfillment of certain services to a third party. think
of the way that linden currently deploys maptiles by way of amazon S3.
for the purposes of managing maptiles, is S3 considered part of the
linden agent domain? functionally it is, but even though it is trusted
by linden,machines that serve the maptile requests will always be
identified as belonging to amazon. (more info at
http://aws.amazon.com/solutions/case-studies/linden-lab/ )

in response to point 1, several of us started to think that we
probably would want to think about what makes a domain a region or
agent domain, and if it's possible to have an "asset domain." this led
to some verbiage in an earlier intro and goals draft that described
"agent domains" as domains that contain an authentication service and
"region domains" as domains that expose an object presence service.
other groups of systems administered by the same entity were simply
"domains"

fortunately, no one noticed we didn't define the term "service"
especially rigorously. but i think there was general consensus that a
"service" was a collection of "protocol endpoints" that performed a
function on behalf of a client. an "endpoint" was an entity with an
address that represented a RESTful resource that could be accessed to
change or query the state of a service. for the most part, we talked
of endpoints as being HTTP(S) urls, as most of us had experience with
doing "OGP over HTTP."

while some of us debated the merits of various terms, others of us
were wrestling with issue 2 above: what constitutes a domain? are all
machines in a domain trusted by each other? what about when you add
services from multiple domains, does that make a new domain? should we
call it something else to highlight the fact that some of the machines
in the domain may not trust other machines in the domain explicitly?
if so, then why the heck do we have the term domain?

one suggestion was to redefine the term "domain" to mean "a collection
of machines." then the term "trust domain" is used to define a
collection of machines that share a trust relationship. a "composite
domain" may be used to describe machines from two distinct trust
domains that cooperate to deliver a service. "services," in turn are
contained entirely in a domain. (so if a service is delivered by
machines in two different trust domains, i.e. it's a composite domain,
then that service is said to be contained by the composite domain, not
the two trust domains that cooperate to deliver the service.)

so. ugh. what do we say about this:

domain - a collection of machines

trust domain - a domain whose members share trust characteristics.

trust characteristic - an abstract description of which entities are
allowed to access which services on which members of a domain.

composite domain - a domain whose members are composed of two or more
distinct trust domains. note that a composite domain may form a new
trust domain.

service - a collection of protocol endpoints that implement a function
(like authentication, inventory, IM, search, etc.)

(protocol) endpoint - the address of a RESTful resource a client may
use to query or change the state of a service.

agent domain - a domain that exposes an authentication service.

region domain - a domain that exposes an object presence services.

comments? questions? death threats?

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com