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

Morgaine <morgaine.dinova@googlemail.com> Mon, 05 October 2009 18:51 UTC

Return-Path: <morgaine.dinova@googlemail.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 3212C3A6833 for <ogpx@core3.amsl.com>; Mon, 5 Oct 2009 11:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.628
X-Spam-Level:
X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_20=-0.74, 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 3XlywEjOWJ7t for <ogpx@core3.amsl.com>; Mon, 5 Oct 2009 11:51:55 -0700 (PDT)
Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 32F533A6863 for <ogpx@ietf.org>; Mon, 5 Oct 2009 11:51:55 -0700 (PDT)
Received: by ewy10 with SMTP id 10so3370668ewy.9 for <ogpx@ietf.org>; Mon, 05 Oct 2009 11:53:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KXoKeyDuldWM52gbWhMB5VW9uKs7s+bbYxb5UAc42JI=; b=VrpdIrtCmcuyiHuymUdUgwNseH4Rr5ykOhnXIUpi3tZ6Mmd1egb7gn1EYXI6ptcGoc n4A9xKxyrvM8GKNcLk7dtVtUkABghiLQqCXEf5JFQPRgvMzJ5dHbTHQPUDwjx79uMZb9 yeUWK3PViLu/me0UK1z+kv7dhoRT6gs8cgyCM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CTJpPWVhegJG0bntThSRP+3uXEKU6w+2LrdQw/snsXycwrIal93qILAusQkYWZnA3O Jix+1RN6kYI7A8kvolLPFPQDClOt670fdsIafxRWxuzJPjZLrRk019hqh+ga10MRKFFh p1RxoGGvTu1yXXWr1a4iUOb/Yv0CHyUwJV+70=
MIME-Version: 1.0
Received: by 10.210.7.23 with SMTP id 23mr422947ebg.27.1254768808524; Mon, 05 Oct 2009 11:53:28 -0700 (PDT)
In-Reply-To: <20091005182505.GA20468@alinoe.com>
References: <20090904195822.GA15341@alinoe.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> <20091002012335.GB690@alinoe.com> <20091005182505.GA20468@alinoe.com>
Date: Mon, 05 Oct 2009 19:53:28 +0100
Message-ID: <e0b04bba0910051153v74f6f26cyedb0c157ca1cf3eb@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Carlo Wood <carlo@alinoe.com>
Content-Type: multipart/alternative; boundary="000e0cdfd7e61b7a98047534a1b5"
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: Mon, 05 Oct 2009 18:51:59 -0000

On Mon, Oct 5, 2009 at 7:25 PM, Carlo Wood <carlo@alinoe.com> wrote:

> Nobody reacted to this post of me so far, does that mean everyone agrees?



I agreed with your approach Carlo when I found total accord with Joshua here
-- http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html .  As you
have probably noticed, we've been moving gradually towards your general
position on RD-controlled region policy just by analysing deployment
requirements.

My post didn't make an arbitrary proposal that the AD's policy be limited to
allowing the TP.  Instead it reasoned out that this was the only known
approach that provides DDP to allow tourism and at the same time allows us
to omit querying AD2 on TP from RD1.

This approach sounds fine to me Carlo, and it's quite simple, symmetrical
and elegant.  What's more, I can't think of any alternative, if we're
constrained to not querying AD2. :-)


Morgaine.




===============================

On Mon, Oct 5, 2009 at 7:25 PM, Carlo Wood <carlo@alinoe.com> wrote:

> Nobody reacted to this post of me so far,
> does that mean everyone agrees?
>
> On Fri, Oct 02, 2009 at 03:23:35AM +0200, Carlo Wood wrote:
> > 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>
> > _______________________________________________
> > ogpx mailing list
> > ogpx@ietf.org
> > https://www.ietf.org/mailman/listinfo/ogpx
>
> --
> Carlo Wood <carlo@alinoe.com>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>