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

Vaughn Deluca <vaughn.deluca@gmail.com> Fri, 02 October 2009 08:42 UTC

Return-Path: <vaughn.deluca@gmail.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 711023A6870 for <ogpx@core3.amsl.com>; Fri, 2 Oct 2009 01:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, 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 TwLw4IXMHJ9h for <ogpx@core3.amsl.com>; Fri, 2 Oct 2009 01:42:55 -0700 (PDT)
Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id E4FF73A6802 for <ogpx@ietf.org>; Fri, 2 Oct 2009 01:42:54 -0700 (PDT)
Received: by bwz6 with SMTP id 6so793768bwz.37 for <ogpx@ietf.org>; Fri, 02 Oct 2009 01:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LG6FFOqX2zlAxnYPhlst5IniiC8LlZhb4FEI/9+yPM8=; b=b3TYnGoIa77it0X9+hqyP5H1ktC0sT3jBfhBHWbj3djH1uooYOpYajG6Z0uyQWnO29 vOWg1utcb3tNQm2yIPHM1BajcUK84BgP39fUEaKHDTsTEflw82+2g5Nh3Lu/mYgfZUK3 Qel7haL5O9FZ0IbufrxdMltuPr59BnlrwiwjI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y6dpOZAPNFBN6+QXwbt5oAO+igT5qniq6u66o/iBl+VFl30133m7DiyNubiNeOq1Y6 4FepJtNl005/TYTMohPmz2Mi+7rJK4L9xN3G4KkfpR0h2l662yw20V/qGBjPRC1tnlkK rHb6HZM4pk7RZTs2GhB4Blhwrgw1pcTcDZ8ps=
MIME-Version: 1.0
Received: by 10.204.156.212 with SMTP id y20mr939826bkw.126.1254473057997; Fri, 02 Oct 2009 01:44:17 -0700 (PDT)
In-Reply-To: <e0b04bba0910012252v540dd170k4b81e30052e6c974@mail.gmail.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@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> <e0b04bba0910011613w6f25b684w1b0f2e8c7187b3de@mail.gmail.com> <f72742de0910011632n3488ff6aqbf93edbda2a51637@mail.gmail.com> <e0b04bba0910012252v540dd170k4b81e30052e6c974@mail.gmail.com>
Date: Fri, 02 Oct 2009 10:44:17 +0200
Message-ID: <9b8a8de40910020144v36077295u314d34d579e21f26@mail.gmail.com>
From: Vaughn Deluca <vaughn.deluca@gmail.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Content-Type: multipart/alternative; boundary="0015175ce1ec0092ca0474efc50d"
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 08:42:58 -0000

Morgaine,

I am equally worried about the problem you sketch in the paragraph below,
however, i think you put the source of that problem in the wrong place. You
argue that if only AD2 is cut out of the equation, all will be fine, and
tourism will be possible. I wish it was true, but even when things are fully
organised as you suggested its the *trust* relations that determine what
will happen, let me explain:

>[...] But instead you might mean the following:  "if RD2 uses some service
of type X, say X2,
>then AD1 cannot provide an X service when in RD2".  That would be extremely
not cool, since
>this would totally block meaningful tourism.

I agree with this sad conclusion, i think the wording could be a lot
sharper, i will come to that below, but loosely speaking you are right. Now
you make the example more explicit:

> For example, RD2 could be using Asset Service AS2, as a result
> of which AD1 would not supply an asset service to its traveling
> agent A1, and hence A1 would never be able to appear in RD2 wearing
> any asset available in W1.

Note that you now say "would not supply" not "cant not provide" as you did
above. This distinction is important. I will follow the more explicit
example, since that is how things are intended IMHO. Also you seem to
suggest an all or nothing behaviour of the asset server that i feel is not
needed, and probably not desirable.

>Clearly this interpretation would mean no useful interop between
>W1 and W2 at all.  I'm hoping this interpretation is wrong.

It would mean no meaningful interop between some of the involved services,
and that as a result of *policy* decisions that can be in *each and every
case* right there where they belong. As i will show below, you can not
escape this situation by trying to deny AD2 any role in the process. The
pain is elsewhere.  Lets do this example a bit more careful:

Our tourist is at home in W1. W1 is a container concept for a collection of
services. The agent is in fact registered in AD1, it uses a big collection
of (purple) clothes from AS1, and is presently located in RD1, trying to
become a tourist and travel for the first time to RD2 (to show off its
purple clothes).

AD1 talks to RD2, trying to gain access rights. RD2 has some age
restrictions, but AD1 manages to convince RD2 its agent is worthy of entry
based on some shared trust of a third party identity provider. No role for
AD2  as you stipulated (although RD2 might have passed responsibility for
this part of the process to AD2, but for clarity lets assume that is not the
case).

Our tourist could now enter RD2 as Ruth. Next AD1 tries to organise the
passage of the purple cloths. That transfer has two endpoints, the asset
service AS1, and RD2. Again RD2 might have some policy what to allow in, and
lets assume its cool with anything, purple or not. Infinity and Carlo looked
at some alien boundary cases, but here we  assume RD2 is happy with any
tourism it can get, including all assets. AS1 on the other hand has
obligations to a large group of purple cloths makers, and will only give out
purple stuff to RD2 if RD2  satisfies some strong conditions.  It has the
protocol means to test those conditions, it *could*  send the purple object,
but does not *want to* based on policy, in particular obligations towards
purple clothes makers  and the lack of trust in the behaviour of RD2. AS1
will however probably send any non-purple clothes to RD2. Cursing under its
breath our tourist might go there in blue, mentally making a note to find a
different clothes shop next time its shopping time.

I completely fail to see what you would like to put in the protocol, or
leave out of it, to remedy this situation.  The would-be tourist has only
one option, and that is to find an asset server that is willing to give out
at least the blue  clothes to RD2.  The restriction in this example is in
AS1 not willing to serve the purple clothes, and AS1 is a service that the
*tourist* has picked. If that turns out to be an unlucky choice and AS1
refuses to give *anything* out to RD2 as you implied in your original
example, the tourist might opt to start using an additional AS, say AS2. If
AD1 in turn  refuses to use AS2 next to AS1, it might really be time to pack
up and move world. Hence my remark (and that of several others) that in the
end interop will be a question of trust, and users will vote with their
feet.
In fact its not even AS1 that is the root of the problem, its the buying
decision of the avatar itself. It might be have been wiser to check more
careful on the export conditions of the purple wonders.

In summary, i see your problem, its big and bad, but i fail to see your
solution. Could you go over this example and point out how things should be
done to prevent the blocked transfer of purple clothes? I do not think that
within the scope of the protocol there is a solution.

Looking in even more detail at the example brings up deeper problems, like
how the clothes maker is going to  know in what AS the purple clothes will
end up. But that is for later i think.

Sorry for the long mail, i will tty to be more brief in the future
Vaughn

On Fri, Oct 2, 2009 at 7:52 AM, Morgaine <morgaine.dinova@googlemail.com>wrote:

> I agree Joshua, I think we are converging. :-)
>
> On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell <josh@lindenlab.com> wrote:
>
>>
>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinova@googlemail.com>wrote:
>>
>>
>>> There *IS* one way of allowing the above, and that is to require that ADs
>>> carry no region-related policies at all, so that consulting only the
>>> destination RD is sufficient.  This would give us a perfect *Destination
>>> Determines Policy* (DDP) system.  The W1 resident could then TP from RD1
>>> to RD2 without consulting AD2 at all.
>>>
>>
> .... and so it looks like we're in agreement ...
>
>
> That's a very good start then.  If ADs have no region-related policies,
> then AD2 clearly doesn't need to be consulted when RD2 is entered from RD1.
>
> Unfortunately, you then wrote:
>
> it should be the case that ADs carry policies about region services...
>
>
> Is there a typo in that?  If it's free of typos and hence ADs carry
> policies about region services, then clearly AD2 *does* have to be
> consulted before you can TP from RD1 to RD2.  (I assume it has a typo, and
> you actually meant to write "do *not* carry policies about region
> services", to make this line consistent with what you said above.)
>
> Leaving the above to be clarified, we seem to be arriving at a *Destination
> Determines Policy* (DDP) model which makes tourism possible, by giving RDs
> control over their region-related policies so that AD2 doesn't need to be
> consulted on entry to RD2.  That's fine, but it's not yet clear how you're
> going to achieve this since you haven't narrowed the scope of the AD to
> exclude region services.
>
> One promising angle stems from this very interesting phrase of yours:
>
> ... by definition the AD2 and RD2 services are disjoint.
>>
>
> It's a bit ambiguous though:
>
>    - If by this you mean that AD1 has no say over region services in RD2,
>    then that's very cool! :-)  (It's cool because it provides DDP and hence
>    allows tourism.)
>    - But instead you might mean the following:  "*if RD2 uses some service
>    of type X, say X2, then AD1 cannot provide an X service when in RD2"*.
>    That would be extremely not cool, since this would totally block meaningful
>    tourism.  For example, RD2 could be using Asset Service AS2, as a result of
>    which AD1 would not supply an asset service to its travelling agent A1, and
>    hence A1 would never be able to appear in RD2 wearing any asset available in
>    W1.  Clearly this interpretation would mean no useful interop between W1 and
>    W2 at all.  I'm hoping this interpretation is wrong.
>
>
> I'd appreciate more info about the disjointness please, to clear up this
> ambiguity.
>
>>
>>
>> I believe I may have misread some of your earlier posts as implying that
>> the agent's AD was not allowed to have a say in policy decisions, only the
>> destination RD. I have a clearer reading of your DDP statement, though, that
>> of course it's the AD reasoning about the RD, and contrariwise the RD
>> reasoning about the AD. If we call that "DDP" then we're copacetic.
>>
>> Ah good, I think we're starting to talk the same language now. :-)  AD1
> has plenty to say in regards to a TP from RD1 to RD2, as long as it sticks
> to the affairs of its own world W1 and its own agent A1.  What it cannot do
> is impose W1's region-related policies on W2's regions, otherwise we end up
> with Vaughn's "war on purple". ;-)   In other words, once in RD2, DDP
> applies and AD1 has no say.
>
> The DDP principle is so obvious from our experience in RL that I didn't
> bother explaining its scope, but perhaps some basic scoping is needed to
> alleviate fears that the source AD has no say at all.  The only thing that
> DDP requires is that the travelling agent *obey the law of the land* on
> arrival in W2, namely the region-related policies that hold in RD2, and not
> those that would hold in a W1 homeworld region like RD1.  It's pretty
> simple, and non-optional if tourism between worlds is desired.  "When in
> Rome, do as the Romans do" says it all.
>
> As you say, I believe we're converging. :-)
>
>
> Morgaine.
>
>
>
>
>
>
>
> =========================================
>
> On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell <josh@lindenlab.com> wrote:
>
>> I think we're converging...
>>
>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinova@googlemail.com>wrote:
>>
>>>
>>> Those are valid examples, but they're cherry picked to support your
>>> specific use case.
>>>
>>>
>> Well, simplified examples. I don't believe more complicated examples
>> actually add meaningfully at a protocol level, as will become clear...
>>
>>
>>> Please examine the more general use case of two complete SL-like worlds
>>> using VWRAP, W1 and W2.  They both have ADs and RDs, so let's label those
>>> with 1's and 2's accordingly.
>>>
>>
>> At a protocol level, I don't think VWs exist. There are services, which
>> we're clustering into AD and RD. Although we may later determine there are
>> further subdivisions, that's our working model in the drafts. Further drafts
>> are strongly encouraged!
>>
>>
>>> If both ADs and RDs determine policy together (as you stated), then you
>>> can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy
>>> coming into play, otherwise you would be subverting AD2's policy.
>>>
>>
>> Here's the crux of the issue: in our model, the provider of W2 is offering
>> two sets of services, AD2 and RD2. There may be a policy covering W2 in
>> general, which would affect the AD2 and RD2 services. However, if an agent
>> "from" W1, meaning the agent services are provided by AD1, attempts to visit
>> RD2, then AD2 does *not* come into play. The protocol describes the
>> negotiation between the client, AD1 and RD2 *only*.
>>
>> (Again, this is insofar as the model in the current drafts are concerned.
>> If we're missing something, please bring the conversation back to the drafts
>> and point out issues and/or submit new work for discussion!)
>>
>> Let me restate: even if AD2 and RD2 are governed by the same policy -
>> potentially even to the point of being implemented by the same monolithic
>> piece of code! - AD2 is irrelevant *from a protocol perspective* in the
>> attempt to place an agent from AD1 into AD2, since by definition the AD2 and
>> RD2 services are disjoint.
>>
>>
>>> There *IS* one way of allowing the above, and that is to require that ADs
>>> carry no region-related policies at all, so that consulting only the
>>> destination RD is sufficient.  This would give us a perfect *Destination
>>> Determines Policy* (DDP) system.  The W1 resident could then TP from RD1
>>> to RD2 without consulting AD2 at all.
>>>
>>
>> .... and so it looks like we're in agreement - if this wasn't clear, then
>> we need to review the drafts (please, go for it!); it should be the case
>> that ADs carry policies about region services... except, of course, that the
>> AD may say "hey, you can't go to *that* RD...".
>>
>> I believe I may have misread some of your earlier posts as implying that
>> the agent's AD was not allowed to have a say in policy decisions, only the
>> destination RD. I have a clearer reading of your DDP statement, though, that
>> of course it's the AD reasoning about the RD, and contrariwise the RD
>> reasoning about the AD. If we call that "DDP" then we're copacetic.
>>
>>
>>
>>> If you wish to define ADs in this way then we are in perfect agreement,
>>> since DDP is essential for interop between worlds.  I am hoping that this is
>>> what you had in mind for when we start discussing specific AD and RD
>>> policies. :-)
>>>
>>
>>
>> _______________________________________________
>> 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
>
>