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

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 29 Mar 2010 10:16:18 -0700

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/ * [email-masked]

---

From: James Hughes <[email-masked]>
Date: Mon, 29 Mar 2010 14:17:15 -0400

On 03/29/2010 01:16 PM, Meadhbh Hamrick wrote:
...
> LL instance. does this mean we should have an "asset domain"?
It would make sense to me to have that capability. The 3rd party asset
services will need to provide functions to interact with both agent and
region domains according to subscription rules and agreements entered
into by operating entities and users. Depending on the rule-set, maybe
the avatar can or cannot see particular inventory items on certain
grids. Or, perhaps, region domains will need to negotiate the ability to
rez or distribute objects based on the rule-sets applied at the 3rd
party service.

It seems pretty complex to administrate with a 3rd party. And, in my
opinion, defining an asset domain to operate in would be useful. Just my
OS$2.

regards
James  (BlueWall)

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 29 Mar 2010 11:19:19 -0700

to clarify, i'm not talking about the capability of using a 3rd party
asset service (which i think we've all agreed is something we should
support) but the use of the term "asset domain" to identify a domain
that exports an asset service.

---

From: Morgaine <[email-masked]>
Date: Mon, 29 Mar 2010 21:36:33 +0100

David dissected the "domain" terminology for us thoroughly last year.  He
very nicely highlighted how the term provides almost no additional value,
because everything is ultimately a "service", and the whole point of VWRAP's
services is that they are highly decoupled to provide a large number of
possible deployments.  "Domain" suggest a stronger coupling than actually
exists.

The idea of "domain" as a control element is not enforceable, nor useful,
when services can be external and the set is expandable.  The notion of
"trust domain" is particularly weak when you don't control external
services, but merely use them.  Drawing circles around sets of services and
calling them "domains" is largely wishful thinking when they are
independent.  You are merely their client rather than their owner:

As an analogy, it's like drawing an "Email domain" circle around an MTA
service and the external DNS services that it uses.  Drawing the circle
provides nothing of value.  All the value is held in the services
themselves, and how they are each configured.

Asset services will exist in their thousands, or millions if the metaverse
catches on.  What this means in VWRAP deployments which support tourism
between worlds is that any given region may contain visitors from arbitrary
many worlds, each visitor bringing references to their own asset services
with them.

So what does "asset domain" mean in this high-interop context?  Virtually
nothing, because the alleged "asset domain" encompasses the whole Internet.
It's a term that belongs with clouds drawn on whiteboards, and doesn't
contribute anything significant to our protocol specifications, because the
domains don't actually exist, only the services.

Morgaine.

===============================

On Mon, Mar 29, 2010 at 7:19 PM, Meadhbh Hamrick <[email-masked]>wrote:

> _______________________________________________
> ogpx mailing list (VWRAP working group)
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: David W Levine <[email-masked]>
Date: Mon, 29 Mar 2010 16:44:20 -0400

[email-masked] wrote on 03/29/2010 01:16:18 PM:

> [image removed] 
> 
> [ogpx] verbiage : domain, agent domain, region domain, trust domain,
> service, etc.
> 
> Meadhbh Hamrick 
> 
> to:
> 
> ogpx
> 
> 03/29/2010 01:17 PM
> 
> Sent by:
> 
> [email-masked]
> 

First, +1 (if not more) on getting the terminology coherent. The time has 
come to speak of things... We need names for the things, and we need those 
names in the base drafts, with nice crisp definitions. 

Names only help when they add real value. If we can't crisply say "This is 
a Blongezorf, and this isn't." we're merely muddying the waters. For 
domain, this is especially tricky as there are several very good and 
normal uses of Domain, both in Distributed Computing, and to and extent 
the casual discussion centering around the specs today. 

>From my perspective, there's a nice progression of things which we can 
define.

We have a set of "messages" which are defined in LLIDL, which laminate 
together into interaction patterns
(Post message X, Get response set Y1-Y7, post message Q) Mark that as a 
"service" , marked off by one or more capabilities.  Those services 
combine into a a cluster of services which form a capital "s" Service, 
such as a "Asset Server" or an "Inventory Service" 

I tend to think about the core "capital S" services as what we're busy 
defining. I'm not at all sure that, given the diversity of deployment 
patterns, defining "Domains" which tie to these into clusters beyond what 
people deploy actually adds any depth to the explanatory framework. I can 
see that there may well be some clusters of "Big S" services which often 
cluster, which may be worth looking at, if there is useful power in naming 
those clusters. Unless those clusters form of necessity, not habitual 
deployment, I'm thinking they would be a non-normative term used elucidate 
rather than define. 

- David
~ Zha

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 29 Mar 2010 13:54:31 -0700

so i said services contain "protocol endpoints" rather than
"capabilities" as it's possible for services to have well defined,
public endpoints that are NOT capabilities.
how 'bout...

the terms "asset domain" and "region domain" are used to identify the
domain of certain types of transactions in the protocol. their use
underscores the potential separation of the roles each domain plays.

so we would say, "the agent domain initiates the process of placing an
agent in a region domain's simulator" rather than "the first service
initiates the process of placing an agent in a region."

so the terms "agent domain" and "region domain" are "positional" and
describe the function in a protocol transaction, NOT a requirement
that a group of machines implement a particular cluster of services.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Mon, Mar 29, 2010 at 1:44 PM, David W Levine <[email-masked]> wrote:
> Names only help when they add real value. If we can't crisply say "This is a
> Blongezorf, and this isn't." we're merely muddying the waters. For domain,
> this is especially tricky as there are several very good and normal uses of
> Domain, both in Distributed Computing, and to and extent the casual
> discussion centering around the specs today.
>
> "service" , marked off by one or more capabilities.  Those services combine
> into a a cluster of services which form a capital "s" Service, such as a
> "Asset Server" or an "Inventory Service"
>

---

From: Morgaine <[email-masked]>
Date: Mon, 29 Mar 2010 22:13:07 +0100

+1 David.

Domains give us nothing normative at all, because of our services deployment
flexibility.  Although they gave OGP a good start, they are becoming less
useful as we identify more services in VWRAP for external deployment.

David's advice regarding service clustering is particularly well given.
When a concept is not a necessity but merely a habitual deployment, it is
not useful to make it a required concept in a spec.  And worse, requiring
that services fit into a "domain" model can reduce the flexibility of how
services are deployed, and creates real problems of definition when these
domains overlap for interop.

We are being poorly served by the "domain" legacy from OGP, and I suggest
that we move beyond that phase into the realm of pure services without
conceptual circles drawn around them.

Morgaine.

======================================

On Mon, Mar 29, 2010 at 9:44 PM, David W Levine <[email-masked]>
wrote:<[email-masked]>

> a Blongezorf, and this isn't." we're merely muddying the waters. For domain,

---

From: David W Levine <[email-masked]>
Date: Mon, 29 Mar 2010 17:14:41 -0400

Meadhbh Hamrick <[email-masked]> wrote on 03/29/2010 04:54:31 PM:

> [image removed] 
> 
> Re: [ogpx] verbiage : domain, agent domain, region domain, trust 
> domain, service, etc.
> 
> Meadhbh Hamrick 
> 
> to:
> 
> David W Levine
> 
> 03/29/2010 04:55 PM
> 
> Cc:
> 
> ogpx, ogpx-bounces
> 

Quite right, on "service endpoint" my bad.

> underscores the potential separation of the roles each domain plays.

In some deployments mayhap. Not in all. The roles the domain plays in 
these
examples is a deployment choice, nothing more. There may be some 
trust/admin
patterns which are common, but then we need to focus on those rather than
thinking calling it an "agent domain" is clarifying. 

> that a group of machines implement a particular cluster of services.

But, positional terms which describe specific patterns, which are 
deployment choices rather
than functional requirements actually confuse not clarify. 

> initiates the process of placing an agent in a region."

It might. Or the authentication service might give you NOTHING more than a 
sheaf of
seed caps each on a stand-alone service which is separately deployed. (I 
think that's
not going to be the most common deployment pattern, but its certainly one 
you could deploy,
and one we need to be able to describe. 

Unless we can say "This is a term which always cuts things into separable 
parts", I think we're 
confusing deployment with architecture. To the degree you can say why 
"Agent Domain" is more
explanatory than saying "This common cluster of services" in which case 
I'm perfectly happy saying that. But
I'm thinking that beyond a very small cluster (Auth, IM endopint, Presence 
broadcast, and even those could be delegated) I'm not sure what HAS to be 
in an Agent Domain, rather than what many people will CHOSE to put in one. 

Please note I think this is exactly the discussion we *should* be having. 
We need to make it clear what the term
is actually buying us, and how we could benefit from it. 

- David
~Zha

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 29 Mar 2010 14:41:28 -0700

On Mon, Mar 29, 2010 at 2:14 PM, David W Levine <[email-masked]> wrote:
> [stuff removed]
> In some deployments mayhap. Not in all. The roles the domain plays in these
> examples is a deployment choice, nothing more. There may be some trust/admin

i don't agree with this statement. it is confusing that a region
domain would host agent services and an agent domain host region
services. it doesn't seem confusing that a domain could be
simultaneously a region domain and an agent domain.

the term "agent domain" identifies the domain that begins certain
types of protocol transactions. if your deployment choice is to have
the agent and region domains be the same domains, then bully for you.
but it doesn't change the fact that there is a collection of hosts
(possibly with a single member, but probably not) that will initiate
certain types of protocol interchanges, and a collection of hosts
(possibly with a single member, but probably not) that will respond to
these interchanges.

> But, positional terms which describe specific patterns, which are deployment
> choices rather

what? no matter what you do, you will have a deployment pattern. no
matter what you do, you will have a host that a request initiates from
and a host that is the target of the request. calling one an "agent
host in an agent domain" clarifies the role the host and domain play,
not the deployment pattern.

if you wanted to deploy chargen, VWRAP authentication and gopher on a
single host, it's still an agent host for the purposes of the
authentication transaction.

> confusing deployment with architecture. To the degree you can say why "Agent
> Domain" is more
> explanatory than saying "This common cluster of services" in which case I'm
> perfectly happy saying that. But
> broadcast, and even those could be delegated) I'm not sure what HAS to be in
> an Agent Domain, rather than what many people will CHOSE to put in one.
>

my recommendation is that the term "agent domain" be "positional"
indicating the role of an actor in a protocol transaction. it DOES NOT
imply service deployment clustering.

a domain is an agent domain for the purposes of authentication if it
responds to the authentication protocol. it is a region domain for the
purposes of teleport if it responds to the teleport protocol. etc.
etc. if you want to put both services on one machine, it is
simultaneously an agent domain and a region domain.

note also that there's nothing in this description that demands that
there be a single agent domain. you could have an agent domain for
authentication or an agent domain for IM and they could be the same or
different agent domains.

-cheers
-meadhbh

> Please note I think this is exactly the discussion we *should* be having. We
> need to make it clear what the term

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 29 Mar 2010 14:42:17 -0700

in other words, "we've been saying 'agent domain' for at least two
years and this is the thing we're hung up on????"

---

From: Morgaine <[email-masked]>
Date: Mon, 29 Mar 2010 23:35:34 +0100

> simultaneously a region domain and an agent domain.

The last paragraph does not seem right, on two fronts.

First of all, it presupposes that each service can *ONLY* occur in a
particular domain, which is not true.  For example, an asset service could
be provided as part of an inventory service under the umbrella called "agent
domain", but an asset service could *also* be provided by a region to hold
its local assets.  This really highlights how the "domain" concept is not
flexible enough to cope with our many types of deployment.

And secondly, if "*a domain could be simultaneously a region domain and an
agent domain*" then "domain" becomes such a loose concept that it is best
avoided entirely --- certainly not normative.

These "domains" are just habitual service clusterings, and should not appear
in the spec because they limit our ability to deploy services wherever we
need them.

Morgaine.

================================

On Mon, Mar 29, 2010 at 10:41 PM, Meadhbh Hamrick <[email-masked]>wrote:

> deployment
> "Agent
> in

---

From: "Robert G. Jakabosky" <[email-masked]>
Date: Mon, 29 Mar 2010 15:10:04 -0800

+1 on using "services" instead of "domains".

On Monday 29, Morgaine wrote:
> because everything is ultimately a "service", and the whole point of
> VWRAP's services is that they are highly decoupled to provide a large
> number of possible deployments.  "Domain" suggest a stronger coupling than
> actually exists.
>
> > On Mon, Mar 29, 2010 at 11:17 AM, James Hughes <[email-masked]>
> >
> > wrote:
> > > grids. Or, perhaps, region domains will need to negotiate the ability
> > > to rez or distribute objects based on the rule-sets applied at the 3rd
> > > party service.
> > >
> > > opinion, defining an asset domain to operate in would be useful. Just
> > > my OS$2.
> > >
> > > regards
> > > James  (BlueWall)
> >

-- 
Robert G. Jakabosky

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 29 Mar 2010 16:30:34 -0700

but what about the trust issue?

are we going to explicitly trust services?

it doesn't make sense that a service is what's trusted as it implies
that something MUST be a vwrap service in order to be trusted.

we created the domain as an abstraction to represent these notions and
again, the idea that there is a domain is INDEPENDENT of how services
are deployed.

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 29 Mar 2010 16:42:50 -0700

if you're saying "we shouldn't dictate how services are deployed" then
you're missing the point of a domain.

a domain is an abstraction which represents characteristics of a
collection of machines that are operating in concert to provide a
service. some of these characteristics are:

  * what service does the domain provide?
  * what end entities on the network does it trust?
  * which are trusted by it?
  * who is the responsible party for the domain?

there is nothing in the definition of a domain that REQUIRES a domain
to deploy services in any way. just because you deploy an
authentication service in a domain, it does not mean that you MUST
deploy a group IM service; or that if you do provide a capability for
a group IM service that it be deployed in the same domain.

in the context of user authentication, the term "agent domain" is used
to describe the collection of network hosts that share trust
characteristics with the host that responds to the request. we could,
when talking about this use case, instead say, "the hosts that share
trust characteristics with the host that implements the authentication
service," but this is a much more unwieldy term.

so if you wanted to operate a grid like the linden grid, then the
hosts that respond to auth, IM, inventory requests would be in a
linden agent domain. if you wanted to operate a tourist instance, then
the agent domain would be the group of machines operated by the person
responsible for granting access to the instance.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: "Robert G. Jakabosky" <[email-masked]>
Date: Mon, 29 Mar 2010 16:07:14 -0800

> you're missing the point of a domain.

No.  I just think that "Asset Service" is clear then "Asset Domain".

> service. some of these characteristics are:

A "Service" can be a "collection of machines that are operating in concert to 
provide a service".  If I run a company the provides an "Email Service" to my 
customer, then I may have deployed many servers to provide that 
one "Service".

>   * what service does the domain provide?

This makes me think you are asking "what services does the 'google.com' domain 
provide?".  At least that would be the first thing that comes to my mind.  I 
know now that the "domain" we are talking about here is not the same thing as 
a domain name like 'google.com'.  But I think it will be confusing to new 
members when they first join VWRAP.

>   * who is the responsible party for the domain?

A company that provides an "Email Service" might use third party DNS/Web 
services from another company to provide the "Email Service" under one domain 
name.  The customer only sees one "responsible party" when dealing with 
the "Email Service".

-- 
Robert G. Jakabosky

---

From: David W Levine <[email-masked]>
Date: Mon, 29 Mar 2010 21:07:41 -0400

At the point where you are describing an "Authentication and Login Domain" 
"Asset Domain" "Inventory Domain" "IM Domain" you are effectively binding 
domain to type of service offered. 

The whole reason I an pushing back so hard on "Agent Domain" is because it 
conflates a specific deployment pattern with something special, and uses 
an already overloaded term. I think a perfectly rational and sane use of 
the term would be to follow common IT and Distributed computing practices, 
such as "Trust Domain" and "Administrative Domain" as well is "IP domain" 
This would allow us to write statements like:

"In this grid, the Login, IM, Presence, Inventory, Group, Search and 
Teleport Services live within a single trust domain. The Regions supported 
by this grid fall into separate administrative and trust domains. This 
grid access a variety of asset and micro-payment services all of which are 
outside both our trust and administrative domain." 

One of the pain points introduced by binding ANY grouping of services into 
the term "domain" at the architectural level is that is implies that this 
specific deployment pattern is privileged within the specifications. The 
closest that I come to thinking that really exists in VWRAP is the cluster 
of services required to support a region. Even here, tho, the pattern, as 
a web pattern, is mostly that of a facade, and the underlying deployment 
of services which actually comprise any specific region may well be 
separated across trust and administrative domains. A rather obvious 
example being the voice services in the second life grid which are 
delegated to Vivox, crossing several "domain" boundaries. 

If we believe there are privileged groupings of services which must be 
clustered and cannot be facaded or separately deployed from other services 
lets enumerate them and understand why they are clustered. 

- David
~ Zha

---

From: Morgaine <[email-masked]>
Date: Tue, 30 Mar 2010 09:19:02 +0100

Again, +1 David.

I see no place for "*privileged groupings of services which must be
clustered and cannot be facaded or separately deployed from other services*".
The only thing that such a privileged grouping achieves is to deny
alternative patterns of deployment.

To give an example, cross-world tourism creates a complex graph of accesses
to asset services which illustrates very well how complex deployments don't
fit into the original "AD+RD" grouping at all.

A popular tourist world may attract visitors from N worlds, none of which
may know about each other.  Each visitor brings into the tourist world items
that are stored in an asset service native to the tourist's home world,
and/or stored in 3rd party asset services, and/or stored in the visitor's
own client-side asset service.

A native of the tourist world will have to be able to access not only her
own world's asset service(s), but also all of the asset services introduced
by tourists, otherwise the world will appear "broken" to her.  Even the
current region itself may introduce a new asset service particular to that
region.

The obvious way to handle such diversity is to avoid predefining any
particular clustering for asset services, but to start from the objects in
the tourist region as the source of references to asset services, and follow
the relevant URIs.

When a visitor first arrives in a region of the tourist world, the visitor's
worn items become known to the region as item references to one or more
asset services.  Whether the region chooses to (i) retrieve and cache the
corresponding data, or (ii) merely hold the references, it is a local
deployment choice.  In the first case all local participating clients will
receive local URIs to the region's own data cache, while in the second case
the clients will receive from the region the external URIs to the remote
assets services.  The latter deployment choice distributes the access load
between clients and asset services very widely across the Internet.

Making prior privileged service groupings in the manner of OGP's "domains"
makes it very difficult to handle this kind of access graph diversity, yet
this tourism deployment pattern is likely to become by far the most popular
in the metaverse, being driven by casual clicking on web pages to find
worlds of interest and visiting them.  By not predefining your service sets,
and instead just "following the data", you obtain the greatest flexibility.

Of course, there are many scenarios in which the freedom of travel needs to
be curtailed, particularly for business and security, and that is perfectly
fine and must be supported as a service option.  It should not be hardwired
into the deployment architecture though, because it is merely a  deployment
choice.  The right way to restrict access options is by configuring which
worlds and which asset services are accessible --- in other words,
service-level configuration, which has an extremely long and respected
pedigree for Internet applications.

Narrowing service deployments into predefined clusters really doesn't help
because ultimately it is the services themselves that have to be configured
and access accepted or denied.  Domains merely hardwire in a habitual
pattern and so restrict our deployment choices unnecessarily, preventing us
from deploying services in other useful patterns by simple service
configuration.

Morgaine.

=============================

On Tue, Mar 30, 2010 at 2:07 AM, David W Levine <[email-masked]> wrote:

> conflates a specific deployment pattern with something special, and uses an
> already overloaded term. I think a perfectly rational and sane use of the
> term would be to follow common IT and Distributed computing practices, such
> as "Trust Domain" and "Administrative Domain" as well is "IP domain"  This
> would allow us to write statements like:
>
> by this grid fall into separate administrative and trust domains. This grid
> access a variety of asset and micro-payment services all of which are
> of services required to support a region. Even here, tho, the pattern, as a
> web pattern, is mostly that of a facade, and the underlying deployment of
> services which actually comprise any specific region may well be separated
> across trust and administrative domains. A rather obvious example being the
> voice services in the second life grid which are delegated to Vivox,
> crossing several "domain" boundaries.
>