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

[Morgaine <[e-mail]>]

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

> On Mon, Mar 29, 2010 at 2:14 PM, David W Levine <[e-mail]> wrote:
> > 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 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 <[e-mail]>wrote:

> On Mon, Mar 29, 2010 at 2:14 PM, David W Levine <[e-mail]> 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/ * [e-mail]
> >>
> >
> > 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
> >
> >
> _______________________________________________
> ogpx mailing list (VWRAP working group)
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>