Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision

David W Levine <dwl@us.ibm.com> Fri, 21 August 2009 16:17 UTC

Return-Path: <dwl@us.ibm.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 0CAC43A6E09; Fri, 21 Aug 2009 09:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.724
X-Spam-Level:
X-Spam-Status: No, score=-5.724 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 qZvFugiQ4G2U; Fri, 21 Aug 2009 09:17:46 -0700 (PDT)
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 2C93B3A6359; Fri, 21 Aug 2009 09:17:46 -0700 (PDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7LGLuDm015768; Fri, 21 Aug 2009 12:21:56 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7LGHpTJ161374; Fri, 21 Aug 2009 12:17:51 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7LGHpgx015911; Fri, 21 Aug 2009 12:17:51 -0400
Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7LGHpAI015906; Fri, 21 Aug 2009 12:17:51 -0400
In-Reply-To: <f72742de0908210910p58b43aeap533c1d52c65aab35@mail.gmail.com>
References: <e0b04bba0908191914h4837045ct777d2c63a30ddaf0@mail.gmail.com> <f72742de0908201600y46311454la8db52c4be1b18dc@mail.gmail.com> <b8ef0a220908201609m1c77be2n3d499b7da20fec5a@mail.gmail.com> <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> <f72742de0908201716i6f5adc29o18313a6e55318a7f@mail.gmail.com> <b8ef0a220908201725l5b9d20d6qcb2921d3547277db@mail.gmail.com> <OF048CEB61.3E58783F-ON85257619.004946AA-85257619.004C6C7B@us.ibm.com> <3a880e2c0908210733v5e2b53a0x889f0f564a573461@mail.gmail.com> <OFBD0DCC89.9430E59E-ON85257619.0056B4DE-85257619.0057FD23@us.ibm.com> <f72742de0908210910p58b43aeap533c1d52c65aab35@mail.gmail.com>
To: Joshua Bell <josh@lindenlab.com>
MIME-Version: 1.0
X-KeepSent: 63080364:5C8B8CC8-85257619:00594CD7; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <OF63080364.5C8B8CC8-ON85257619.00594CD7-85257619.005985E0@us.ibm.com>
From: David W Levine <dwl@us.ibm.com>
Date: Fri, 21 Aug 2009 12:17:50 -0400
X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/21/2009 12:17:50, Serialize complete at 08/21/2009 12:17:50
Content-Type: multipart/alternative; boundary="=_alternative 005985DE85257619_="
Cc: ogpx-bounces@ietf.org, ogpx@ietf.org
Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision
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: Fri, 21 Aug 2009 16:17:48 -0000

Either of those is fine with me. I think the former is crisper, the later 
slightly
more elegant. (And yeah the repeat's annoying, but its hard to avoid)


I think, we're about ready to say "last call" on comments. 

- David W. Levine 



Joshua Bell <josh@lindenlab.com> 
Sent by: ogpx-bounces@ietf.org
08/21/2009 12:10 PM

To
ogpx@ietf.org
cc

Subject
Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision






I do think this is one of the places in the charter where using "virtual 
world(s)" is justified; the crisper wording may not imply much about the 
intent to folks outside the effort, and (to Morgaine's point) seems very 
abstract even to those inside the effort. Much of the draft charter 
feedback we've gotten is that "concrete is a good thing"!

How about a tweak:

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these virtual world 
services to interoperate, when permitted by policy and shared trust 
domains.

Or:

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these services to 
interoperate, when permitted by policy and shared trust domains, enabling
the creation of interoperating virtual worlds.

(This rather short paragraph repeats "interoperate", "trust domain" and 
"policy" twice, alas.)

On Fri, Aug 21, 2009 at 9:01 AM, David W Levine <dwl@us.ibm.com> wrote:

Fair enough. So.. Let me try an even crisper wording. 

>>> 
Regions and Services implemented according to the specifications may be 
deployed by separate organization with varying policies and trust domains. 

The OGPX protocols will provide the mechanisms for these services to 
interoperate, 
when permitted by policy and shared trust domains. 
>>> 




Infinity Linden <infinity@lindenlab.com> 
08/21/2009 10:33 AM 


To
David W Levine/Watson/IBM@IBMUS 
cc
Meadhbh Siobhan <meadhbh.siobhan@gmail.com>om>, ogpx-bounces@ietf.org, 
ogpx@ietf.org 
Subject
Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision








i would argue that we shouldn't be introducing a term into the charter
that we can't define. the term "virtual world" is more appropriate for
the MMOX effort. OGP has an intentionally loose definition of the term
"virtual world," and it means (roughly) "the set of places you can
teleport or walk to." this is NOT a feature that is defined by
protocol, but by trust.

there is absolutely nothing in the protocol that requires region
operator 'A' to trust region operator 'B' or agent domain operator
'C'. we do, however, define message formats and techniques to carry
artifacts of this trust. there is nothing in the PROTOCOL that defines
who trusts who.

this is EXACTLY the issue that torpedoed PEM and led to MOSS and later
S/MIME. the protocols MUST NOT define trust relationships for
operators. they MUST be deferred to deployers. because we cannot
define trust in the protocol, it is inappropriate to insert language
in the charter based on that assumption.

if you define the term "virtual world" as "the set of places you can
teleport to" then this term CAN'T have meaning because it depends on
local policy that is out of the control of the protocol specifiers.
this is why the term is not used. this is why we define the protocol
in terms of things we CAN make some assumptions about: the required
parties in a protocol transaction. in the case of teleport, this
includes the originating region, the target region and the agent
domain.

this is the moral equivalent to saying the following in the ssh
specification "every ssh server must define a user called 'root', and
that user must have full permissions over the server." as it happens,
a great number of ssh servers have a superuser named root, but some
don't. there's no reason to define it in the protocol because it's a
matter of local policy.

when we say "there are things called virtual worlds, and they're
defined as the set of all places you can teleport to," what does that
give us? from a protocol perspective, it gives us nothing, because we
will never user it.

as part of the introduction, we may want to say "this protocol can be
used to construct a set of connected regions that MAY be rendered by a
client application in a form that appears as a virtual world." but
this gets us what?

-cheers
-meadhbh

On Fri, Aug 21, 2009 at 6:54 AM, David W Levine<dwl@us.ibm.com> wrote:
>
> I am going to suggest inserting a very  concise paragraph after the 
second
> paragraph.
>
>>>> Insert
>
> Regions and Services implemented according to the specifications may be
> assembled into
> multiple virtual worlds. These worlds may embody multiple domains of 
trust.
> Deployed virtual
> worlds may support different policies of use. Constrained by these 
policies,
> the protocols will
> permit interoperation across OGPX  virtual worlds with compatible 
policies
> and trust models.
>
>>>> end insert
>
> I poersonally think this is implicit, but making it explicit doesn't 
hurt.
>
> I think this preserves the separation of concern we desire. Mechanisms 
are
> defined at the
> protocol level. Policy is defined separate from mechanism. It should be
> possible to deploy
> everything from highly constrained walled gardens to very open grids. 
The
> degree of
> avatar, agent, service and digital goods flow between specific virtual
> worlds will vary according
> to the policies, and trust boundaries established by deployers. Nothing 
in
> the specifications
> dictates specific policies
>
> This follows the existing  practices of the web and internet.The core
> protocols
> and formats of the internet permit interoperation, but deployers 
routinely
> constrain
> the accessibility and reach of services based on policy.
>
>
> - David W. Levine
> ~ Zha Ewry (ISL)
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>


_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx

_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx