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

[Vaughn Deluca <[e-mail]>]

Morgaine,

>We have made a rod for our own backs by defining domains as enforcers of
policy, instead of leaving
> policy to the services.

I see domains merely as a convenience making it easier to organise things.
Indeed as David says, the service will ultimately enforce the policy, yet if
a service is deployed within the domain you might as well say the domain
enforces the policy by *picking* this particular service. Its just wordplay.

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

I do not like the way you frame the situation here. I am interested in my
own freedom to experience a unified virtual world, irrespective of the
underlaying ownership of services. I have no objection against people
running their own worlds in the way they like. The word "cartel" implies
that  i have no other options, and  are forced to use something i don't
like. The protocol should give me the freedom to do things the way i do
like. Yet, I can *not* demand control over resources i do not own. If i take
residence in W1 (better: if i subscribe to AD1) that does not give me any
right to configure asset services used by AD1.

I might expect however that AS1 will give me back anything i trusted it
with. But if i put object in AS1 that carry export restrictions, i know AS1
will under certain conditions refuse to send that object outside its
jurisdiction. Nothing wrong with that. Its *my* choice to put the object in
AS1.

I do expect however that AS1 will allow me to take to RD2 anything that
carries *no* restrictions. If AS1 is not flexible enough to determine what
it can give out to RD2 and what not, and therefore refuses to give out
anything to RD2, i would be disappointed, and feel compelled to store all my
stuff in AS2, that acts more intelligent (Alas, I will not be able to put my
purple clothes in AS2, because the maker does not want to sell to me if i
don't put them in AS1 first and AS1 does not want to give them out to AS2).
 I would certainly expect that when I am in AD1/RD1 I can get access to AS2
were i have a lot of other  stuff, and in this way prevent the need to copy
or move everything from AS2 to AS1 before i try to use it in RD1.

My conclusion is the protocol should allow me to contact  *any* AS i choose.
But it is up to RD1 to decide if it wants to accept stuff from my chosen AS
(that's your DDP). If RD1 has a policy that prevent me from rezzing anything
 but objects from AS1, and AS1 insists on giving objects only to RD1, well
thats fine, but i am not going to live in such a world. It might mean though
i have to stop wearing the nice purple clothes only sold in RD1,  (or more
precise, only sold if placed in AS1). But regarding the protocol, the
important question is if it allows me access to AS2 when in AD1. As soon as
that is the case, i have my freedom.

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

I should have been more clear, i meant to say that i don't see how *any*
protocol  change can solve this problem since we are actually discussing
trust and rights issues. Doing away with domains will not help. So probably
its wrong to call it a "problem" in the sense that it needs solving before
we can proceed. That is not the case. We should focus on the *possibility*
to use external services when in a particular domain, and i feel confident
there are very workable solutions for that, that will make all parties
happy.

-Vaughn

On Sun, Oct 4, 2009 at 9:50 AM, Morgaine <[e-mail]>wrote:

> 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 <[e-mail]>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 <[e-mail]>wrote:
>>
>>> I agree Joshua, I think we are converging. :-)
>>>
>>> On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell <[e-mail]> wrote:
>>>
>>>>
>>>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <
>>>> [e-mail]> 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 <[e-mail]> wrote:
>>>
>>>> I think we're converging...
>>>>
>>>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <
>>>> [e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ogpx mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>
>>>
>>
>