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

Meadhbh Hamrick <ohmeadhbh@gmail.com> Mon, 29 March 2010 21:41 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 A01413A6B80; Mon, 29 Mar 2010 14:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.123
X-Spam-Level: *
X-Spam-Status: No, score=1.123 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 yFmi1Y79KqJH; Mon, 29 Mar 2010 14:41:23 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 5B2BB3A6989; Mon, 29 Mar 2010 14:41:22 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 9so415584qwb.31 for <multiple recipients>; Mon, 29 Mar 2010 14:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=oSp4rD+40Z/FibSE2JQlDOZ+KSOi+WTWRvWMKKPWKMs=; b=qRUqFPB8haUUv0sx/AvNNTrNdDxdusRLJpOzI4xSji5LJbWWlixKpUULn8qhLvT//X xJjXhgldsBcE6tCMLSuR6AlKDM9QkiQW/FbzGXR5iek3X9zESvVKf5kiyG7NnKVZYIA0 Qexnhge/k122UrJpoieUjo45m5zwZ7hlyy4Pg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=cIb348/nWSm9hiPndbJC894DaGXjCV/ex1uFur941t0lYkDrL0xdwdeqhE+UGbz6Pd 2ieHuU7c8GCyAjP93tLVJL0dxBESf59xSwkd/MOaNz5kQQ7/58N6Rwmo6IhnpoJk/t4x cSFVj2jN47zs0v4iUEyDIJUL/07/BKCWraKpU=
MIME-Version: 1.0
Received: by 10.229.20.209 with HTTP; Mon, 29 Mar 2010 14:41:28 -0700 (PDT)
In-Reply-To: <OF6751600F.91798AA3-ON852576F5.00734CF3-852576F5.0074B3AA@us.ibm.com>
References: <b325928b1003291016i5c07e6d9na0feda9faf930aeb@mail.gmail.com> <OFBFBED893.69AA3E2B-ON852576F5.006184FA-852576F5.0071ECAF@us.ibm.com> <b325928b1003291354r37aa88daq1bebc63c5d65e6af@mail.gmail.com> <OF6751600F.91798AA3-ON852576F5.00734CF3-852576F5.0074B3AA@us.ibm.com>
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
Date: Mon, 29 Mar 2010 14:41:28 -0700
Received: by 10.229.10.132 with SMTP id p4mr2117677qcp.86.1269898908120; Mon, 29 Mar 2010 14:41:48 -0700 (PDT)
Message-ID: <b325928b1003291441v32ea8504t2431ecb681fd87ba@mail.gmail.com>
To: David W Levine <dwl@us.ibm.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: ogpx-bounces@ietf.org, ogpx <ogpx@ietf.org>
Subject: Re: [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 21:41:24 -0000

On Mon, Mar 29, 2010 at 2:14 PM, David W Levine <dwl@us.ibm.com> wrote:
> [stuff removed]
>>
>> 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.
>>
>
> 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.

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.

>
>
>> 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/ * OhMeadhbh@gmail.com
>>
>
> But, positional terms which describe specific patterns, which are deployment
> choices rather
> than functional requirements actually confuse not clarify.

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.

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

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
> is actually buying us, and how we could benefit from it.
>
> - David
> ~Zha
>
>