Re: [ogpx] Updated deployment and trust draft posted

"Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com> Wed, 24 February 2010 19:13 UTC

Return-Path: <infinity@lindenlab.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 0E8393A8574 for <ogpx@core3.amsl.com>; Wed, 24 Feb 2010 11:13:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level:
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 bvqnPyMqOeGa for <ogpx@core3.amsl.com>; Wed, 24 Feb 2010 11:13:19 -0800 (PST)
Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 7D8453A8572 for <ogpx@ietf.org>; Wed, 24 Feb 2010 11:13:18 -0800 (PST)
Received: by fxm5 with SMTP id 5so5615448fxm.29 for <ogpx@ietf.org>; Wed, 24 Feb 2010 11:15:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.239.193.139 with SMTP id j11mr11812hbi.127.1267038922157; Wed, 24 Feb 2010 11:15:22 -0800 (PST)
In-Reply-To: <OF985E62D1.9C6EC6C9-ON852576D4.005FCAC1-852576D4.006031EE@us.ibm.com>
References: <OFE468F9B5.25216572-ON852576CD.0053ADC1-852576CD.0053E11E@us.ibm.com> <382d73da1002170836x3c689a89ve5e62a67e6173bdc@mail.gmail.com> <OF7F0480B9.5C99B16B-ON852576CD.00623CB9-852576CD.006335DE@us.ibm.com> <e0b04bba1002180129if2eeabv5eb7f7db76bfaf1d@mail.gmail.com> <6c9fcc2a1002180918p2bf40959v32a1163848c76717@mail.gmail.com> <20100219141252.GA16509@alinoe.com> <b8ef0a221002190817q1131fdf0v87c4b48f62839baa@mail.gmail.com> <20100221105631.GA32748@alinoe.com> <OF985E62D1.9C6EC6C9-ON852576D4.005FCAC1-852576D4.006031EE@us.ibm.com>
From: "Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com>
Date: Wed, 24 Feb 2010 11:15:02 -0800
Message-ID: <3a880e2c1002241115w7fcb906di208f8c3eb8aac0ec@mail.gmail.com>
To: David W Levine <dwl@us.ibm.com>
Content-Type: multipart/alternative; boundary="001485f630dedf308604805d7ceb"
Cc: ogpx@ietf.org
Subject: Re: [ogpx] Updated deployment and trust draft posted
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: Wed, 24 Feb 2010 19:13:22 -0000

good draft... so... since there's no trust model and deployment pattern
deliverable in the charter, do we want to split this one up and put the
deployment stuff in the intro and the trust stuff in the auth draft?

here are some comments:

* eek! you mentioned Linden Lab(tm) and Second Life(tm) in the draft. given
last week's conversation about "second life-like" vs. "vwrap-like" as a
descriptor, shouldn't we avoid such things for fear of people thinking that
if they're SL-compatible, they're automagically VWRAP-compatible?

* i love the picture of User 1 <-> Client 1 <-> service <-> Client 2 <->
User 2. it's kind of an oversight that i didn't put something like that in
the intro doc. (though i would show it with multiple services.. something
like
https://wiki.secondlife.com/w/images/d/da/Vwrap_user_to_service_mapping.png)

in a related issue. we use the term "client application" for an app that
accesses services. the most visible client application is the one that
renders the virtual world for the user. i think this kind of application is
traditionally called a "user agent" in other IETF protocols. so...

question : does it make sense to introduce the concept of a "user agent" as
the client application that is intended to have direct interaction with the
user?  i think it would be good to explain that "clients" or "client
applications" do not always have to be "user agents." if so, lemme modify
the intro doc to reflect it.

* i would argue that the definition of a "domain" IS defined. as we agree'd
on the list, we use the term "domain" in it's classic meaning: "a domain is
a collection of network hosts under the control of a single administrative
authority."

there was an unfortunate confusion of the term "domain" with "administrative
authority" as well as the convolution of the terms "domain" and "network
host." the existing documents describe a domain in this manner, highlighting
an "agent domain" as a domain that includes a user authentication service
and a "region domain" as a domain that includes a region object presence
service. i'm still not sure why we have to change this.

david, i understand that your preference is to have domain mean "the
collection of machines which combine to deliver a service." this is going to
get confusing when a "domain" crosses "trust domains." in other words, if
you have machines owned by one person delivering half of a service and
machines owned by another person delivering the other half of the service,
and you want to call both sets of machines taken together "a domain," then
it will get confusing to also call the set of machines owned by the first
person (even the ones that aren't delivering the service in question) "a
domain."

so... i think we have a couple of different concepts here, and we have to
name them different things. maybe we could compromise... we could say that a
domain is "a collection of hosts that share some common feature" and that a
"trust domain" is a collection of hosts with the same trust characteristics
(defined as being owned by the same entity or for whom there's
a demonstrable privilege implying trust) and a "service domain" is a
collection of hosts that together, deliver a service with the special note
that a service domain may cross trust domains.

ugh. that was a mouthful.

* yup. the glossary in the intro should be beefed up. i'll add some to it.

<comment mode="pedantic">
* why are we mentioning hypergrid? they've publicly said they don't want to
participate. can we remove mentions of hypergrid from these specs? i have no
problem with individuals who participated in hypergrid from participating in
vwrap (like i could do anything to prevent it.) but... vwrap IS NOT
hypergrid. vwrap is also not Second Life. vwrap is also not OpenSim, OSGrid,
reactionGrid, cable beach or realXtend.

i think we need to be very clear about the relationship between this effort
and these projects. as i see it, vwrap is an effort sponsored by the IETF
which is intended to be useful by all of the projects listed above, but not
to "be" them.

in other words, i have a big problem with using the ostensive definition
when describing vwrap service definitions. i don't want to ever have a spec
that says (and i paraphrase here) "readers are referred to hypergrid
specification 3.71 for how vwrap handles authentication to an asset service
and the legacy second life protocol as defined in the beginning of file
llagent.cpp from the snowglobe source code."

on the other hand... getting people from all of the projects mentioned above
together to define protocol and usage profiles is a bag full of win. but we
should be able to define the characteristics of these systems independent of
their names. or rather, we should talk about characteristics of protocol and
use and then maybe say ("like hypergrid" or "like opensim".)

sorry for going all pedantic on people. just think strongly it would be a
train wreck to do this thing that is probably not what david is saying we
should do, but scares me nonetheless.
</comment>

* i think you've got some good ideas WRT trust. however... can we avoid
talking about content management IN the protocol? it's a can of worms and
IMHO is out of scope and needs A LOT more research. that being said... yes,
it's important and we MUST talk about it, but maybe we could add it to a
separate document?

in other words, i propose adding bits about trust between hosts in the
authentication document, but not about content management.

-cheers
-meadhbh

--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.com/wiki/User:Infinity_Linden


On Wed, Feb 24, 2010 at 09:30, David W Levine <dwl@us.ibm.com> wrote:

>
> Dear all:
>
> I have updated the deployment patterns and trust draft with
> significant new material and (hopefully) typos removed.
>
> I look forward to comments and feedback. On the list please. I will
> happily take typo nits and formatting suggestions off list, but
> substantive feedback should be directed to the list for everyone
> to see.
>
> Text at:
>
> *http://www.ietf.org/id/draft-levine-vwrap-deploy-01.txt*<http://www.ietf.org/id/draft-levine-vwrap-deploy-01.txt>
>
> - David W. Levine
> ~ Zha Ewry (in Second Life)
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>