Re: [ogpx] VWRAP Draft Charter - 2009 09 01

Carlo Wood <carlo@alinoe.com> Fri, 02 October 2009 01:21 UTC

Return-Path: <carlo@alinoe.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 DE18C3A681E for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 18:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.185
X-Spam-Level:
X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
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 NKjJHEo0LWxa for <ogpx@core3.amsl.com>; Thu, 1 Oct 2009 18:21:10 -0700 (PDT)
Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id 21BCA3A6837 for <ogpx@ietf.org>; Thu, 1 Oct 2009 18:21:09 -0700 (PDT)
Received: from edge03.upc.biz ([192.168.13.238]) by viefep13-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091002012234.UAQB28202.viefep13-int.chello.at@edge03.upc.biz>; Fri, 2 Oct 2009 03:22:34 +0200
Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id ndNY1c03b0FlQed03dNZoK; Fri, 02 Oct 2009 03:22:34 +0200
X-SourceIP: 77.250.43.12
Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from <carlo@alinoe.com>) id 1MtWrv-0002NH-5X; Fri, 02 Oct 2009 03:23:35 +0200
Date: Fri, 02 Oct 2009 03:23:35 +0200
From: Carlo Wood <carlo@alinoe.com>
To: David W Levine <dwl@us.ibm.com>
Message-ID: <20091002012335.GB690@alinoe.com>
References: <e0b04bba0909022028g68227199t86212294fe6faefc@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <e0b04bba0909132243r10730a3fq275f8143087807c6@mail.gmail.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <e0b04bba0909291751g157d2043g1c15e8d8ac417ccf@mail.gmail.com> <f72742de0909300910t23131532i1719d2c86423fa41@mail.gmail.com> <e0b04bba0910011434i13f890bfodd22cd15eef17697@mail.gmail.com> <f72742de0910011457o5e757135rd9db7fc7f4a1389@mail.gmail.com> <OFBDE64925.B257B8B0-ON85257642.007957C9-85257642.007B2CA5@us.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <OFBDE64925.B257B8B0-ON85257642.007957C9-85257642.007B2CA5@us.ibm.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: ogpx@ietf.org
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01
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, 02 Oct 2009 01:21:13 -0000

On Thu, Oct 01, 2009 at 06:25:22PM -0400, David W Levine wrote:
> We need to be careful, when looking at this stuff to strike a balance between
> focusing on the current deployed clusterings, and turning everything into soup.
> That said, the actual deployed systems which implement these specifications are
> only going to be able
> to enforce policy at the interfaces we define, and these interfaces are on
> services, not domains.

It is because we can't allow *every* possible deployment to be supported (soup)
that I brought up my worries about which service should determine policy (ToS).

It would be easy to choose a simplification (== not allow every possibility)
that leaves out a deployment that is essential, imho.

My proposal was this:

The AD can only allow a user to connect to (teleport to) a region (domain)
or not. If it allows a user to teleport there, then everything that that
domain allows is allowed.

I probably should have been more clear about this from the beginning:
this (my concern) has everything to do with where Abuse Reports go to:
Once a user is in a given region and breaks a policy (or not) and someone
else wants to report this user, then the only authority that this report
should go to is the administration of the region (personally, I even
advocate the sim, but alas).

If to whomever an 'abuse report' goes has nothing to do with VWRAP
than we can skip this topic; but I think it might be relevant and it
is certainly something we need to keep in mind while designing the
protocol (to make sure that won't go wrong).

Example:

Region RD1 runs on servers in country X whose laws state that adult
content may be accessed at the age of 16 or older. However, the
administration of RD1 has it in their ToS that one has to be 18.
They do not see a reason to ban people of age 16 or 17 however.

Agentd AD2 is seated in another country where one has to be 21 before
one is allowed to access adult content.  AD2 does age verification.

If a person of age 18 logs in with AD2 and tries to TP to RD1 then
* AD2 may disallow that if they so choose.
* If AD2 allows the TP, than the user is allowed to access adult
  content by the ToS of RD1 if their age is 18 or older.

If the user lives in a country where 18 is old enough as well,
than I don't think that it matters (legally) where the AD2 is
seated: the administration of AD2 cannot be sued for allowing
a person to teleport to RD1 (I hope :p).

***************************************************************
* Hence, it is possible to apply the simplication:            *
*- AD policies ONLY come into play at the moment of teleport  *
*  (allow or not).                                            *
*- Once arrived in a new region, the policies of the AD can   *
*  be 'forgotten' and only the policies of the RD apply.      *
*  If the AD doesn't want that, they shouldn't allow the TP.  *
***************************************************************

We shouldn't take this simplification (or deployment limitation) too
lightly, but I think it is one that will work VERY well in practice
and well worth it, as it's benefits will far outweight the disadvantages,
imho.

If anyone can think of a clear counter example where a TP should
be allowed but still the AD ToS should determine what is allowed
and what not, please let us know.

A clear advantage of this simplification is that it makes
it trivial where an Abuse Report would go to: namely the to the
administration of the Region (domain).

A clear disadvantage of NOT making this simplification is that
it would be totally unclear where Abuse Reports have to go, and
that lots of confusion will arise about who can do what and why
they can and you not.

-- 
Carlo Wood <carlo@alinoe.com>