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 > >
- [ogpx] A blog post from the HTML5/Websocket wars … David W Levine
- Re: [ogpx] A blog post from the HTML5/Websocket w… Kari Lippert
- Re: [ogpx] A blog post from the HTML5/Websocket w… David W Levine
- Re: [ogpx] A blog post from the HTML5/Websocket w… Morgaine
- Re: [ogpx] A blog post from the HTML5/Websocket w… Barry Leiba
- Re: [ogpx] A blog post from the HTML5/Websocket w… Carlo Wood
- Re: [ogpx] A blog post from the HTML5/Websocket w… Meadhbh Hamrick
- Re: [ogpx] A blog post from the HTML5/Websocket w… David W Levine
- Re: [ogpx] A blog post from the HTML5/Websocket w… Joshua Bell
- Re: [ogpx] A blog post from the HTML5/Websocket w… Carlo Wood
- [ogpx] Updated deployment and trust draft posted David W Levine
- Re: [ogpx] Updated deployment and trust draft pos… Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Updated deployment and trust draft pos… Lawson English
- Re: [ogpx] Updated deployment and trust draft pos… Morgaine
- Re: [ogpx] Updated deployment and trust draft pos… Carlo Wood
- Re: [ogpx] Updated deployment and trust draft pos… Meadhbh Hamrick