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

Morgaine <morgaine.dinova@googlemail.com> Sun, 04 October 2009 07:49 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 70EB03A6912 for <ogpx@core3.amsl.com>; Sun, 4 Oct 2009 00:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.622
X-Spam-Level:
X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=-0.505, 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 vvU9Rc+J-+Mt for <ogpx@core3.amsl.com>; Sun, 4 Oct 2009 00:49:15 -0700 (PDT)
Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 9043D3A68F1 for <ogpx@ietf.org>; Sun, 4 Oct 2009 00:49:14 -0700 (PDT)
Received: by ewy28 with SMTP id 28so3057174ewy.42 for <ogpx@ietf.org>; Sun, 04 Oct 2009 00:50:43 -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=LJPEQNNihvJYEywya1peMFJnolZSnYDnFO5kDGTWAk8=; b=kfzIqXPQh5k1e89YPFPUwWcLRCEXk+DevmLfM9a0yAY6Tyvlg7x9RbXyCm+qe9Fptl zWyJ7FlCabgkujLQqY8eZ0b5SWMXHmCoiEiNBZGneR5sXko6f451hHsxQ6QfLN5oJhGw qxG/r/1K4QtUWrfKufD1qkef2G/rrNlxcP19I=
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=W5tukHT7OQ4x6mpy7jEtlkYGpYwVxXDWIaKHD7ONNwY0eCnNpphSf/j72LcdvIIDSO 0gJ7QNc6K0qFRW4JO+GTfXa3uNAUejAToLYaB92TyzoPht5wO3Ed0QudWsqCO6YsXR+W zLamqlhHVjzIGYOFZNFHF8BxM9KPQjfg6ehok=
MIME-Version: 1.0
Received: by 10.211.159.11 with SMTP id l11mr5285264ebo.78.1254642643244; Sun, 04 Oct 2009 00:50:43 -0700 (PDT)
In-Reply-To: <9b8a8de40910020144v36077295u314d34d579e21f26@mail.gmail.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.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> <9b8a8de40910020144v36077295u314d34d579e21f26@mail.gmail.com>
Date: Sun, 04 Oct 2009 08:50:43 +0100
Message-ID: <e0b04bba0910040050g3861008er33ff2c9d0eaf054@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Vaughn Deluca <vaughn.deluca@gmail.com>
Content-Type: multipart/alternative; boundary="001636d3464012195604751741fd"
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: Sun, 04 Oct 2009 07:49:18 -0000

Vaughn, I think I'm with you on the problems you've highlighted, although
perhaps I'd better tick the paragraphs to be sure:

On Fri, Oct 2, 2009 at 9:44 AM, Vaughn Deluca <vaughn.deluca@gmail.com>wrote:

> 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:
>


It should be noted that I'm trying to cut AD2 out of the equation mainly
because this is one of Joshua's requirements stemming from the original OGP
scheme.  If our various goals can be achieved without needing to involve AD2
then all the better, since reduction of complexity is always a good thing,
so I support Joshua in that.

As it happens, it is possible to achieve DDP using Joshua's scheme by
limiting ADs to agent policies and RDs to region policies, and therefore I'm
happy with this approach.  However, I am fully aware that this doesn't
always make tourism possible, since it still requires the cooperation of
both worlds.  A prison world will not let its inmates escape, and a closed
society will not allow foreign visitors to enter, so just because DDP makes
tourism *possible*  doesn't mean that individual world policies will always
allow it.


>
> >[...] 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.
>


While this is catastrophic for interop in multi-world deployments, note that
Joshua has already accepted this and recognized that asset service
contributions are required from both W1 and W2.  Although we are still
working out the details, the point is already somewhat moot because the
severity of the problem has been accepted.

Note that I offered one solution to this problem at the end of this post --
http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html .  It's
really simple, and boils down to asset services being provided entirely by
the RDs.  RD1 provides access to the asset service AS1 (typically proxy
access --- after all, SL's regions already work as proxies to an asset
service, so it's no big leap), while RD2 provides access to the asset
service AS2.  No AD can ever provide an asset service, and therefore AD2
does not need to be consulted on TP.


>
> 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.
>
>
I meant *cannot provide*, very specifically.  The reason is that my analysis
stemmed from Joshua's statement about *disjointness* of AS and RD services.
The "cannot" is a mathematical "cannot", in the sense that if the AD and RD
service sets are *disjoint*  then the same services cannot appear in both.
Joshua accepted the problem and softened his phrase to the funny "mostly
disjoint". :D

Note that my proposal resolved this quite simply by requiring asset services
to be provided only by RDs.  This gives us the DDP necessary for tourism (or
*potential*  tourism, I should say), plus it allows assets from W1 and W2 to
appear in RD2, and it does not require AD2 to be consulted.  That seems
quite a nice package deal.



> >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 believe that I understand your point.  You are describing the situation
that arises when W1 policy overrides the user-chosen policy that the user
encodes in her assets in AS1.

I agree that this is an issue.  I pointed it out here
http://www.ietf.org/mail-archive/web/ogpx/current/msg00433.html in answer to
David's statement that "services are going to manage policy, not the domains
they reside in",  Clearly David's statement doesn't quite reflect where we
are at the moment with the protocol, in which domains are totally crushing
the policies of services, although of course it is still early days. :-)



> 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.
>


I think that my view on this is more in tune with David.  We have made a rod
for our own backs by defining domains as enforcers of policy, instead of
leaving policy to the services.  If we had left policy to the services then
a user would be able to configure her asset service AS1 to allow purple
clothing to enter RD2, despite the cartel operating in W1 seeking to
restrict any travel while wearing purple clothing.


> 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.
>
>
You may be right to be worried.  The protocol as it stands denies any
possibility of such user freedom.  Perhaps domains should be removed from
the model altogether, leaving just services.


An interesting post, Vaughn, thanks. :-)


Morgaine.




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



> 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
>>
>>
>