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

[Morgaine <[e-mail]>]

I'm totally in accord with you on all points here, Joshua.

You raised a question about what I meant in one particular section, and the
answer to that is *initially*  that "it's fine under your preferred
interpretation".  However, further down I then show that we're forced to
merge the two interpretations for symmetry or "bad things happen", so it
turns out not to be an either/or answer.  This was your query:

On Fri, Oct 2, 2009 at 4:55 PM, Joshua Bell <[e-mail]> wrote:

>
> On Thu, Oct 1, 2009 at 10:52 PM, Morgaine <[e-mail]>wrote:
>
>>
>> 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.)
>>
>>
> Did you mean AD2 or AD1? I agree for AD2. For AD1, being nitpicky, here's a
> scenario that possibly contradicts that: if RD2 tries to give you inventory,
> AD1 may refuse it since it is the final arbiter of your agent (and hence
> your inventory). I'm not sure if that counts as "say over region services"
> or not. Based on previous conversation, I think we agree that in that
> scenario, AD1 is enforcing agent-related policy in the interaction with
> region services, not "having a say" over those region services.
>


That you agree for AD2 is crucial, so let's accept that, and let's leave AD1
contributing to A1's asset service policy when in RD2 (as well as in charge
of asset service policy in RD1 for consistency) for now as you suggest.
(This is going to change slightly when we look at its ramifications in a few
paragraphs.)



>    - 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.
>
> This is an extremely good point. "Disjoint" was too strong a word. I don't
> think we've sorted out assets yet, but from early brainstorming, asset
> services could indeed be provided by both ADs and RDs. (And a VW provider
> might host just one asset service that its ADs and RDs both reference.)
> "Mostly disjoint" :)
>


Excellent. :-)  It's great that this point is taken and we understand that
asset service cannot come *only* from the destination RD, nor from W1
alone.  Unfortunately, this means that now the key paragraph I wrote in
answer to David in post
http://www.ietf.org/mail-archive/web/ogpx/current/msg00449.html comes into
play, which I'll rewrite here for easy reading and with more explanation
added:

If ADs are allowed to provide caps to asset services *in any deployment
pattern whatsoever*, then AD2 will *always* have to be consulted if it
exists, *in all deployments*, because nobody knows what kind of deployment
pattern is used in W2, so AD2 might be providing asset services as well as
RD2.  This affects our protocol very strongly --- looking for an AD2 and
querying it if it exists will not be optional.


By noting that we require Asset Services contributions from both W1 and W2,
then if the W1 contribution is made to come from AD1, we have lumbered
ourselves with the need to consult AD2 because of symmetry (if AD1 can
provide asset services then so can AD2, so it must be consulted).  This is
not what we wanted.

I can see two ways out of this dilemma:

   1. Let the W1 asset service contribution come *not from AD1* but from *
   RD1*.  This not only avoids the need to consult ADs on asset services,
   but it is also nicely symmetrical for both source and destination, and it
   also respects the maxim "ADs do not provide region-related services" and
   hence allows DDP.  This is the clear winner on all counts.
   2. Alternatively, define another domain to carry asset services, such as
   a Storage Domain, so that ADs do not need to provide region-related
   services.  I don't see any real benefit in this, given that option 1 seems
   so good.  It's just substituting an SD2 lookup in place of the unwanted AD2
   lookup.  That's close to being a mere word change so I don't find any real
   merit in it.


Option 2 is so bad (I think) that really I'm only proposing option 1.
Option 1 makes the VWRAP model in respect of asset services very simple and
symmetric, as well as consistent with our common view in the last pair of
emails:


   - ADs do not provide any asset services at all.
   - RDs are the sole providers of asset services.  These asset services are
   provided to all three categories of agent: (i) homeworld residents in a home
   RD, (ii) homeworld residents touring in other worlds, and (iii) foreign
   tourists arriving in the home RD from other worlds.


Such a scheme avoids needing to consult RD2, while still providing A1 with
W1 assets to carry into RD2 for full interop alongside W2's assets provided
by RD2.  And of course it's a DDP scheme since RD2 has full control over its
own policies, so this allows full tourism.


How does this sound?


Morgaine.








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

On Fri, Oct 2, 2009 at 4:55 PM, Joshua Bell <[e-mail]> wrote:

>
> On Thu, Oct 1, 2009 at 10:52 PM, Morgaine <[e-mail]>wrote:
>
>>
>> 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.)
>>
>>
> Ugh, yes, typo... I indeed meant to echo your statement: "ADs carry no
> region-related policies". Thanks for catching that.
>
>
> 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.)
>>
>>
> Did you mean AD2 or AD1? I agree for AD2. For AD1, being nitpicky, here's a
> scenario that possibly contradicts that: if RD2 tries to give you inventory,
> AD1 may refuse it since it is the final arbiter of your agent (and hence
> your inventory). I'm not sure if that counts as "say over region services"
> or not. Based on previous conversation, I think we agree that in that
> scenario, AD1 is enforcing agent-related policy in the interaction with
> region services, not "having a say" over those region services.
>
>
>>
>>    -
>>    - 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.
>>
>> This is an extremely good point. "Disjoint" was too strong a word. I don't
> think we've sorted out assets yet, but from early brainstorming, asset
> services could indeed be provided by both ADs and RDs. (And a VW provider
> might host just one asset service that its ADs and RDs both reference.)
> "Mostly disjoint" :)
>
>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>