Re: [ogpx] Updated deployment and trust draft posted

[Lawson English <[e-mail]>]

I see an issue where there is a presumption of external "authority" with 
respect to services. A client plugin might provide a vwrap service only 
to a client via a localhost/loopback mechanism, or it may be a proxy to 
a central service or it may be a proxy to a p2p network of services. 
Where does administrative authority lie in this scenario? Does it 
pertain? Who decides? etc...

lawson


Infinity Linden (Meadhbh Hamrick) wrote:
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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_
>
>     - David W. Levine
>     ~ Zha Ewry (in Second Life)
>
>
>     _______________________________________________
>     ogpx mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ogpx
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>