Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter)

From: "Infinity Linden (Meadhbh S. Hamrick)" <[email-masked]>
Date: Fri, 06 Feb 2009 02:34:45 -0800

Hi John, Morgaine,

Yes. Speaking as the co-chair of the BoF, I share your concerns. The draft group charter is exactly that, a draft. I think we expect it to be modified before the WG is formed. The draft does take a very Linden-IBM perspective as those were the authors of the draft. The IETF standardization process REQUIRES consensus, so I don't think we're expecting a rubber-stamp.

But, we would like to get people to submit concrete proposals. So let me ask; do you think you guys could come up with verbiage that could be inserted into the charter that would address your concerns? If you look at the charters of other groups, you'll sometimes find wording indicating the group has an exploratory mission as well as one to work on explicit proposals. It sounds like you both would be interested in such language. So, please submit changes to the draft documents you wish to discuss here. If you will attend the meeting in San Francisco, there's space in the agenda for open discussion and Q&A should your concerns not be addressed on the list.

With respect to LLSD, there is a precedent for including vendor names in the names of drafts and RFCs. RFC2437 PKCS#1 : RSA Cryptography Specifications and RFC2040 describing the RC5 cipher (RC5 stands for both "Ron's Code 5" and "Rivest Cipher 5)

We brought LLSD into the public as part of OGP and as an internet draft so we could get comments from the internet community. It might be advantageous if you could describe which portions of the LLSD draft you think need modification.

With regards to hypergrid, can it be specified in the form of an internet draft and discussed here? Is there a willingness by its authors to submit it as a standard?

Cheers!
Meadhbh

Morgaine Dinova <[email-masked]> wrote:

>On Fri, Feb 6, 2009 at 7:47 AM, Hurliman, John <[email-masked]>wrote:
>
>> As it is written, the charter and timeline effectively subverts
>> investigation of virtual world platform requirements and the evaluation of
>> different technologies that fulfill those requirements. The charter
>> specifically lists technology proposals from Linden Lab as established
>> solutions to virtual world interoperability. The goals and milestones
>> section lists a timeline for standardizing those solutions exclusively. I
>> understand the need to transition Linden Lab proposals to standards, and I
>> support such a move but not at the expense of excluding all other possible
>> solutions. I propose that the charter and timeline be changed to ensure the
>> agenda is open to additional proposals.
>
>
>John, if the charter, goals and timeline are as you describe, then I agree
>with you 100%.  Rubberstamping existing Second Life technology as a standard
>for virtual worlds would be totally without merit, and endorsing LL's
>current very narrow and unproven OGP solution as THE future Internet
>standard under the aegis of the IETF would be ... well, let's not go there.
>It would clearly be inappropriate, and unhelpful to the development of
>virtual worlds.
>
>However, I do not believe that that is the purpose of this workgroup,
>because you will note that the charter is only a draft in expectation of
>strong input from MMOX members (and OGP is Work in Progress anyway).  Let's
>provide that input immediately, to prevent this starting off on the wrong
>foot.
>
>The charter needs to be phrased unambiguously to make it clear that this
>workgroup is not an IETF PR annex of Linden Lab, but that it is dedicated
>honestly to the creation of a flexible, vendor-agnostic protocol for
>interoperation of diverse virtual worlds, not just now but for several years
>into the future.  That implies extensibility, in breadth and in depth.  And
>it implies openess to alternatives, and a desire to embrace them,
>
>And in particular, it implies a focus on technical merit of solutions, and
>not current business interests.
>
>I agree that we appear to have been given a slightly questionable baseline
>in LLSD ("Linden Lab Structured Data" is hardly a vendor-agnostic name) and
>OGP (Linden Lab's own developing protocol) without any mention of
>alternative approaches like Hypergrid that are already in operation.
>However, these skews and omissions are (I believe) just artifacts of the
>rush to establish MMOX.
>
>Let's see how we can improve this.  I think that it's in our court to set
>the path straight.
>
>Morgaine.
>_______________________________________________
>mmox mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmox

---

From: Morgaine Dinova <[email-masked]>
Date: Fri, 6 Feb 2009 11:41:12 +0000

On Fri, Feb 6, 2009 at 10:34 AM, Infinity Linden (Meadhbh S. Hamrick) <
[email-masked]> wrote:

> Hi John, Morgaine,
>
> Yes. Speaking as the co-chair of the BoF, I share your concerns. The draft
> group charter is exactly that, a draft. I think we expect it to be modified
> before the WG is formed. The draft does take a very Linden-IBM perspective
> as those were the authors of the draft. The IETF standardization process
> REQUIRES consensus, so I don't think we're expecting a rubber-stamp.

Good, that is of course what I was hoping (and expecting) to hear.  Let's
make sure that the charter reflects our openness and makes our work of value
to more parties than just the current participants in the SL ecosystem.

But, we would like to get people to submit concrete proposals. So let me
> ask; do you think you guys could come up with verbiage that could be
> inserted into the charter that would address your concerns?

Yes, I'll try to help with this.  Getting the charter right is largely just
a matter of naming the end goal and cutting out SL-specifics.

With respect to LLSD, there is a precedent for including vendor names in the
> names of drafts and RFCs. RFC2437 PKCS#1 : RSA Cryptography Specifications
> and RFC2040 describing the RC5 cipher (RC5 stands for both "Ron's Code 5"
> and "Rivest Cipher 5)
>

While the use of "Linden Lab" in the name is not vendor-agnostic and hence
might well cause problems of adoption by your competitors (and you cannot
seriously be suggesting that LL ranks alongside Rivest!), that is not the
key problem with the name, which is the following.

LLSD is in current use inside LL/SL, and so it cannot be both that
production format and a modified extensible format that we will be refining
at the same time.  (It may not change, but at this stage we cannot know
that.)  To use John's form of words in the LLSD context, using this
established technology PRECLUDES CHANGE if we find that change is required.
After all, it is not within our scope to modify LL's current internal
format.

Personally I would have avoided the issue by replacing all occurrences of
"Linden Lab" by "Open Grid" in this Structured Data spec for MMOX as a sign
that the OGP protocol is fully independent of LL, and to avoid any friction
with other companies.  "Open Grid Structured Data" also happens to fit in
with "Open Grid Protocol" like hand in glove.

Morgaine.

---

From: Rob Lanphier <[email-masked]>
Date: Fri, 06 Feb 2009 10:09:18 -0800

On 2/6/09 3:41 AM, Morgaine Dinova wrote:
> production format and a modified extensible format that we will be
> refining at the same time.  (It may not change, but at this stage we
> cannot know that.)  To use John's form of words in the LLSD context,
> using this established technology PRECLUDES CHANGE if we find that
> change is required.  After all, it is not within our scope to modify
> LL's current internal format.

A common activity in the IETF is work on Informational RFCs, which
aren't intended to be standards track proposals, but as formalized
specifications of technology already in widespread use.  These are
especially helpful for things like MIME-type registrations, and provide
good reference works for future standards-track specifications.

You'll see from the draft that LLSD is being proposed as Informational
track.  That doesn't preclude the creation of a future specification,
also called LLSD, that is a standards track specification, but that's
going to be something that the proposed working group can sort out.

Given how widely used LLSD is already in several independent
implementations, it seems like it's at least worthy of an Informational
RFC and a MIME-type registration, no?

Rob

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 6 Feb 2009 11:22:19 -0800

I'm the sponsoring AD for this BOF, and I'm glad to see work on making the
charter more generic already.  It wasn't clear to me how interested other
parties besides Linden Labs were, and what they want, but that's what the
BOF process (not just the meeting, but also the mailing list and its charter
discussions ) is for.  The goal is to figure out The Right Thing to do, and
nothing is set in stone yet.  The right thing could even be more than one
WG, for example.

It's worth pointing out very early that the deadline for submitting new
Internet-Drafts is March 2, and there's a tradition of only considering
material that has been published in Internet-Drafts at IETF meetings.  Thus,
if there's any other material that can be put in the form of an
Internet-Draft and published by March 2, then that document is referenced in
the agenda, a lot of IETF people will read that material and be better
prepared for this BOF.

In particular, people like me who haven't been involved in this area will
need a bit more introduction somehow.  I actually have read some of this
Open Grid stuff before, and yet I'm still struggling with what it means for
two nodes to share perceptions of things or to handoff control of virtual
objects.  What about trust between nodes?  What about differences in how
things are modeled and what metadata they have?

thanks,

Lisa

On Fri, Feb 6, 2009 at 3:41 AM, Morgaine Dinova <
[email-masked]> wrote:

> With respect to LLSD, there is a precedent for including vendor names in
>> the names of drafts and RFCs. RFC2437 PKCS#1 : RSA Cryptography
>> Specifications and RFC2040 describing the RC5 cipher (RC5 stands for both
>> "Ron's Code 5" and "Rivest Cipher 5)
>>
>

---

From: Lawson English <[email-masked]>
Date: Fri, 06 Feb 2009 14:04:08 -0700

Lisa Dusseault wrote:
> I'm the sponsoring AD for this BOF, and I'm glad to see work on making 
> the charter more generic already.  It wasn't clear to me how 
> interested other parties besides Linden Labs were, and what they want, 
> but that's what the BOF process (not just the meeting, but also the 
> mailing list and its charter discussions ) is for.  The goal is to 
> figure out The Right Thing to do, and nothing is set in stone yet.  
> The right thing could even be more than one WG, for example.
>
> It's worth pointing out very early that the deadline for submitting 
> new Internet-Drafts is March 2, and there's a tradition of only 
> considering material that has been published in Internet-Drafts at 
> IETF meetings.  Thus, if there's any other material that can be put in 
> the form of an Internet-Draft and published by March 2, then that 
> document is referenced in the agenda, a lot of IETF people will read 
> that material and be better prepared for this BOF. 
>
> In particular, people like me who haven't been involved in this area 
> will need a bit more introduction somehow.  I actually have read some 
> of this Open Grid stuff before, and yet I'm still struggling with what 
> it means for two nodes to share perceptions of things or to handoff 
> control of virtual objects.  What about trust between nodes?  What 
> about differences in how things are modeled and what metadata they have?
>

Those are hot-button questions, Lisa, due to the "live" economy that 
Second LIfe uses. There's been more discussions on those topics than 
anything else, I suspect.

Here's an index to most of the discussions I'm aware of about these topics:

https://wiki.secondlife.com/wiki/AW_Groupies#Chat_Logs

key words: permissions, perms, IP, intellectual property, content 
creation, content creators,  inventory, assets, copybot...

See alsp: https://wiki.secondlife.com/wiki/Category:AW_Groupies_User_Pages

> thanks,
>
> Lisa
>
> On Fri, Feb 6, 2009 at 3:41 AM, Morgaine Dinova 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Fri, Feb 6, 2009 at 10:34 AM, Infinity Linden (Meadhbh S.
>     Hamrick) <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         Hi John, Morgaine,
>
>         Yes. Speaking as the co-chair of the BoF, I share your
>         concerns. The draft group charter is exactly that, a draft. I
>         think we expect it to be modified before the WG is formed. The
>         draft does take a very Linden-IBM perspective as those were
>         the authors of the draft. The IETF standardization process
>     Good, that is of course what I was hoping (and expecting) to
>     hear.  Let's make sure that the charter reflects our openness and
>     makes our work of value to more parties than just the current
>     participants in the SL ecosystem.
>
>         But, we would like to get people to submit concrete proposals.
>         So let me ask; do you think you guys could come up with
>         verbiage that could be inserted into the charter that would
>         address your concerns?
>
>
>     Yes, I'll try to help with this.  Getting the charter right is
>     largely just a matter of naming the end goal and cutting out
>     SL-specifics.
>
>         With respect to LLSD, there is a precedent for including
>         vendor names in the names of drafts and RFCs. RFC2437 PKCS#1 :
>         RSA Cryptography Specifications and RFC2040 describing the RC5
>         cipher (RC5 stands for both "Ron's Code 5" and "Rivest Cipher 5)
>
>
>     While the use of "Linden Lab" in the name is not vendor-agnostic
>     and hence might well cause problems of adoption by your
>     competitors (and you cannot seriously be suggesting that LL ranks
>     alongside Rivest!), that is not the key problem with the name,
>     which is the following.
>
>     refining at the same time.  (It may not change, but at this stage
>     we cannot know that.)  To use John's form of words in the LLSD
>     context, using this established technology PRECLUDES CHANGE if we
>     find that change is required.  After all, it is not within our
>     scope to modify LL's current internal format.
>
>     Personally I would have avoided the issue by replacing all
>     occurrences of "Linden Lab" by "Open Grid" in this Structured Data
>     spec for MMOX as a sign that the OGP protocol is fully independent
>     of LL, and to avoid any friction with other companies.  "Open Grid
>     Structured Data" also happens to fit in with "Open Grid Protocol"
>     like hand in glove.
>
>     Morgaine.
>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: David W Levine <[email-masked]>
Date: Fri, 6 Feb 2009 18:04:10 -0500

Great to see you asking questions Lisa. 

Two separate issues. Trust, can be viewed as straightforward, but hard. We 
have the usual kitbag of PKIX style solutions, which is good, in the sense 
that tools like X.509, TLS and HTTPS give us good ways to manage 
authenticating a remote node in the internet as someone we understand, but 
bad, in the sense that large scale deployments of PKI based solutions are 
expensive, and non trivial to manage.  There has been a long, ongoing 
discussion about applying X.509, and such to provide a basis for 
establishing shared trust, and then layering policy based choices on top 
of that. (What degree of trust, can I extend to a service which offers me 
this trust token? things of that sort) 

I started to right a long answer to your second question, but, it was 
turning into an essay on immersive space design. The short form of the 
answer is, yes, this work needs to allow for virtual space services to 
expose the type of model(s) they support, as well as they styles of 
interaction they support. Likewise, there are issues akin to content 
negotiation, when adding objects into a simulated region, and, several 
approaches to how a simulation should be deployed as a process (Single 
unitary service, peer to peer mesh of services, clients off-loading 
various degrees of processing, etc) 

There are some good leverage points, which factor out the common tasks in 
all these approaches, namely, adding inputs to the simulation, progressing 
the simulation, and notifying interested parties of the results. In some 
cases, this will look very much like the "Region simulator" model which 
Linden Lab, and a number of other virtual worlds adopt, where simulation 
is unitary, in others, it may involved a set of peers, as are found in 
Croquet, which share the state of the world, and then model it locally. 
The degree to which such approaches can share the content which flows 
between them, is unclear, but probably greater than zero. ("Object 17, is 
rotating according to this vector" is something that would be expressed in 
many of the different approaches, for example) 

I expect that, this work will end up being a mix of very concrete efforts 
to document building blocks, with much more abstract  work to allow us to 
express multiple styles of interactions using shared building blocks. If 
we can, in fact identify the shared building blocks, and can specify them 
to everyone's satisfaction, I would hope that would create draft 
specifications which would advance interoperability broadly. 

- David W. Levine
~ Zha Ewry (ISL) 

Lisa Dusseault <[email-masked]> 
Sent by: [email-masked]
02/06/2009 02:22 PM

To
Morgaine Dinova <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
Re: [mmox] Work Items and Planning Documents for the MMOX BoF   session 
(Draft Charter)

I'm the sponsoring AD for this BOF, and I'm glad to see work on making the 
charter more generic already.  It wasn't clear to me how interested other 
parties besides Linden Labs were, and what they want, but that's what the 
BOF process (not just the meeting, but also the mailing list and its 
charter discussions ) is for.  The goal is to figure out The Right Thing 
to do, and nothing is set in stone yet.  The right thing could even be 
more than one WG, for example.

It's worth pointing out very early that the deadline for submitting new 
Internet-Drafts is March 2, and there's a tradition of only considering 
material that has been published in Internet-Drafts at IETF meetings. 
Thus, if there's any other material that can be put in the form of an 
Internet-Draft and published by March 2, then that document is referenced 
in the agenda, a lot of IETF people will read that material and be better 
prepared for this BOF. 

In particular, people like me who haven't been involved in this area will 
need a bit more introduction somehow.  I actually have read some of this 
Open Grid stuff before, and yet I'm still struggling with what it means 
for two nodes to share perceptions of things or to handoff control of 
virtual objects.  What about trust between nodes?  What about differences 
in how things are modeled and what metadata they have? 

thanks,

Lisa

Yes. Speaking as the co-chair of the BoF, I share your concerns. The draft 
group charter is exactly that, a draft. I think we expect it to be 
modified before the WG is formed. The draft does take a very Linden-IBM 
perspective as those were the authors of the draft. The IETF 
standardization process REQUIRES consensus, so I don't think we're 
expecting a rubber-stamp.

Good, that is of course what I was hoping (and expecting) to hear.  Let's 
make sure that the charter reflects our openness and makes our work of 
value to more parties than just the current participants in the SL 
ecosystem.

Yes, I'll try to help with this.  Getting the charter right is largely 
just a matter of naming the end goal and cutting out SL-specifics.

LLSD is in current use inside LL/SL, and so it cannot be both that 
production format and a modified extensible format that we will be 
refining at the same time.  (It may not change, but at this stage we 
cannot know that.)  To use John's form of words in the LLSD context, using 
this established technology PRECLUDES CHANGE if we find that change is 
required.  After all, it is not within our scope to modify LL's current 
internal format.

Personally I would have avoided the issue by replacing all occurrences of 
"Linden Lab" by "Open Grid" in this Structured Data spec for MMOX as a 
sign that the OGP protocol is fully independent of LL, and to avoid any 
friction with other companies.  "Open Grid Structured Data" also happens 
to fit in with "Open Grid Protocol" like hand in glove.

Morgaine.

---

From: Morgaine Dinova <[email-masked]>
Date: Sat, 7 Feb 2009 11:56:31 +0000

On Fri, Feb 6, 2009 at 11:04 PM, David W Levine <[email-masked]> wrote:

> establishing shared trust, and then layering policy based choices on top of
> that. (What degree of trust, can I extend to a service which offers me this
> trust token? things of that sort)
>
> I suggest that we stay well clear of the perceptual minefield that is the
enumeration of trust and security benefits as marketing bullet points.  Some
very perceptive and well respected minds in the security area have
highlighted in recent years the great disparity between the actual benefits
provided by security mechanisms and the far higher but quite false sense of
security that they generate.

We're not marketeers (particularly of snake oil), so let's try to stick to
objective technical benefits of the specific solutions that we propose,
justifying those benefits as analytically as we can, and leave the debatable
systemic merit of these mechanisms for others to advocate, probably
incorrectly.

Security is a very complex and challenging engineering problem, but security
theater isn't engineering at all.

Morgaine.

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Sat, 7 Feb 2009 09:42:19 -0800

Right. our plan is to provide mechanism, but not policy, and certainly  
not security theater. There is no way the developer of a protocol can  
ensure that the user of that protocol will follow best practice in  
terms of security. But I don't think the answer is to ignore security  
concerns.

In terms of security, we've already had significant conversations in  
the AWG about domains of trust, or what's trying to trust what and  
when. My sense is that it's worth enumerating these domains in a  
protocol definition and provide default mechanisms to ensure trust.  
For the trust domain that yields to PKIX/X.509 style solutions, X.509  
is convenient as 1) it's well defined, 2) there's a history of  
identifying and fixing it's problems, and 3) it separates the policy  
of key management (the policy of the certifying authority and explicit  
roots trusted by a node) from the mechanism (PKIX, OCSP, etc.)

So to recap... there are several different places where trust must be  
defined. some of them will require host authentication. PKIX is a good  
fit for these types of solutions. Deployers who want a "federated  
trust" experience can deploy a full PKI, with all it's benefits and  
drawbacks. Those who don't care can simply use self-signed  
certificates and can explicitly trust "promiscuous" root certificates.

That said... we should remember that we'll eventually need actual  
proposals in the form internet drafts, or at least in the form of  
"security concerns" sections of other drafts.

Maybe we should add to the charter of the working group the  
requirement that we identify trust domains and investigate options for  
each domain. So... the domains identified in the past include:

1. host to host domain. this is the domain of "do i even trust the  
host i'm connecting to." for some types of deployments, say a public  
deployment like Second Life, the server components will decide to  
trust each client host. for private, commercial deployments, the  
operators may only want to trust a few select systems.

2. inter-object domain. so assuming you trust the host you're talking  
to, if it's an endpoint for asset information, you may want to know  
that the assets involved or it's meta-data is "trusted" somehow. or...  
there have been at least a few proposals to encrypt assets. the reason  
inter-object is different from host-to-host is that it is conceivable  
that a trusted host may hold assets who's origin is unknown. while it  
is (probably) outside the definition of any protocol we define here as  
to what client applications will do with object-based trust  
information, we should either define the format for trust or privacy  
asset meta-data or identify how to add opaque information in asset  
formats.

-cheers
-m/∞

On Feb 7, 2009, at 3:56 AM, Morgaine Dinova wrote:

> Two separate issues. Trust, can be viewed as straightforward, but  
> hard. We have the usual kitbag of PKIX style solutions, which is  
> good, in the sense that tools like X.509, TLS and HTTPS give us good  
> ways to manage authenticating a remote node in the internet as  
> someone we understand, but bad, in the sense that large scale  
> deployments of PKI based solutions are expensive, and non trivial to  
> manage.  There has been a long, ongoing discussion about applying X. 
> 509, and such to provide a basis for establishing shared trust, and  
> then layering policy based choices on top of that. (What degree of  
> trust, can I extend to a service which offers me this trust token?  
> things of that sort)
>
> I suggest that we stay well clear of the perceptual minefield that  
> is the enumeration of trust and security benefits as marketing  
> bullet points.  Some very perceptive and well respected minds in the  
> security area have highlighted in recent years the great disparity  
> between the actual benefits provided by security mechanisms and the  
> far higher but quite false sense of security that they generate.
>
> We're not marketeers (particularly of snake oil), so let's try to  
> stick to objective technical benefits of the specific solutions that  
> we propose, justifying those benefits as analytically as we can, and  
> leave the debatable systemic merit of these mechanisms for others to  
> advocate, probably incorrectly.
>
> Security is a very complex and challenging engineering problem, but  
> security theater isn't engineering at all.
>
> Morgaine.

---

From: Morgaine Dinova <[email-masked]>
Date: Sat, 7 Feb 2009 22:09:17 +0000

> RFC and a MIME-type registration, no?

Highly worthy, Rob! :-)

What's more, since it is the technical issues that matter to us most here,
the fact that Linden Lab appears in a protocol name barely registers on the
importance radar at all, except possibly to yourselves if you want to see
LLSD adopted as a standard even by your competitors.  It's not an issue as
far as I am concerned, as long as the standard is totally unencumbered for
use in the virtual world community or any purpose.

What would be an issue though would be LL's production LLSD acting as a
brake on modifications of the serialization format that might be required by
this workgroup for the purposes of extensibility.  Since you have explained
that LLSD is free to evolve if needed (and it may not even be needed), I do
not forsee a problem at this time.

If LLSD is modified by us then you will have to tackle versioning if the old
name is retained, but that's not a showstopper.

Morgaine.