Re: [ogpx] Protocol for permitting policy decisions

[Morgaine <[e-mail]>]

Magnus, you're mixing up my analysis of what's required for Joshua's scheme
to work, with my recognition that we need a more flexible approach based not
on this restrictive AD+RD split but on the much more flexible decoupled
services behind them.

When I speak of AD1+RD1 and AD2+RD2 in the analysis, this is *not at all  *the
actual deployment scenario that any of us expects to see.  It's just the
smallest case that allows us to say something concrete about the problems
with the original OGP design when extrapolated to the multi-world deployment
scenario.  So please don't attribute any narrow vision in this scenario to
me --- I'm fully aware that it's artificial and is going almost nowhere.
I'm merely doing a smallest-possible scenario analysis.

My personal interest is in the fully expanded and massively scaled
deployments which the AWG group in SL was originally formed to consider 2
years ago (this might give you some idea of the scale ---
https://wiki.secondlife.com/wiki/Project_Motivation ) , but there's no point
describing a massively complex deployment example when a simpler one
suffices to make a specific point. :-)

So to your post ...

On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig <[e-mail]> wrote:

> Morgaine,
>
> No, you are still stuck in the concept of one virtual world equals one AD
> plus one RD, even if you say you recognize a future more complex service
> pattern. VW=AD+RD does not have to be the case with VWRAP.



I know that it's artificial.  We're merely examining this small scenario to
highlight an elementary problem with distribution of services, and it has
already been useful.  It has demonstrated that even in this miniscule
example, there need to be (i) asset service contributions from *both* worlds
in the example, so just a single inventory service in AD1 is not adequate,
and (ii) that if ADs control region policy then AD2 must be consulted as
well since it has every bit as much right to determine policy in RD2 as does
AD1, or more.  These are important constraints on the design, despite the
deployment example being such a simple one.

In addition to the case shown, there are simpler cases and there are more
complex cases.

The simpler cases, such as no AD2 exists, or only W1 asset services are used
in W2, can be handled by the original OGP design, so they wouldn't have
served the purpose here.  More complex cases, such as multiple RDs in W2, do
not add value to the particular point being made, so why complicate the
scenario unnecessarily?  We'll certainly need them later, but they don't
help here.

Obviously multi-world deployment scenarios such as we expect to be common in
the metaverse are going to have much more complex deployment patterns
involved a myriad of concurrent services, but adding that complexity at this
point doesn't enhance the present argument.


If it _happens_ to be the case and the entity controlling AD2 and RD2 wants
> to enforce AD2 policy for those visiting RD2, then they can move, duplicate
> or mirror the enforcement of that policy from AD2 to RD2, which they can do
> without problems as long as they control both. If they don't control both,
> then it's entirely up to the entity controlling RD2 if they for some reason
> want to enforce the policy of the entity controlling AD2. So I see no reason
> whatsoever why symmetry is required.
>


Ah, here you've simply misunderstood me:  you think I'm talking about *
deployment* symmetry, but I'm not.  I'm talking about
*definition*symmetry:  if ADs are defined to be able to control region
policies, then by
symmetry that applies to all ADs.  It wouldn't make sense to say "ADs are
defined to carry region policy, but this only applies to our ADs and not to
yours."  ;-)  That's what I mean by this applying symmetrically.

Deployment patterns are of course arbitrary and don't have to be
symmetrical:  two interoperating worlds can individually be using any
deployment pattern they choose, and one world of the pair will generally
have no say on the deployment pattern used by the other.  Across the whole
metaverse, we can expect every single possible deployment pattern to be used
by someone, and for added spice, tourists from every possible deployment
could be visiting some common tourist world to create a kaleidescope of
combined deployments in the region.



> Policy is not decided and enforced by the AD, the RD or any service
> connected with them, it is decided and enforced by the entities behind them.
> If the same entity controls an AD and a RD, then it's meaningless to try to
> divide up that entity's policy into AD policy and RD policy, because it can
> enforce that policy at any level, type of domain or connected service it
> controls.
>


Sure, but someone has to code this stuff.  It's not helpful to say "Anything
can be done anywhere", because that would mean that the protocol would at
every decision point have to gather policy contributions from all possible
endpoints.  It *can* be done this way of course, but if a simpler design
suffices then a more compex one may not be a good idea.

That said, take note of David's advice about policy being best implemented
in the services themselves.  Domains are not necessarily bad, but they do
actually restrict our flexibility substantially compared to using decoupled
services alone.


>
> But, like you, I am totally in favor of letting the entity controlling the
> destination RD decide policy once the agent is there. However, if the
> agent's own AD for some reason wants to stop the agent from going there,
> then I think it should have the possibility to do so. In all honesty, I
> don't think an AD imposing undue restrictions on where people are allowed to
> go or what they are allowed to do there will survive for long though, once
> competition is in place. You may have to start out fresh, with a new AD,
> without the assets and inventory connected to the old AD, but I think most
> people are willing to take that step if they feel their freedom is too
> limited.



Well in my case I'm not merely "*in favour*" of region policy control by
regions.  I don't think it's actually optional in multi-world deployments,
because without Destination Determines Destination Policy there can be no
viable multi-world tourism at all, and that's the primary use case with
massive popular interest.  We wouldn't have much of a metaverse without it.


Morgaine.





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


On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig <[e-mail]> wrote:

> Morgaine,
>
> No, you are still stuck in the concept of one virtual world equals one AD
> plus one RD, even if you say you recognize a future more complex service
> pattern. VW=AD+RD does not have to be the case with VWRAP. If it _happens_
> to be the case and the entity controlling AD2 and RD2 wants to enforce AD2
> policy for those visiting RD2, then they can move, duplicate or mirror the
> enforcement of that policy from AD2 to RD2, which they can do without
> problems as long as they control both. If they don't control both, then it's
> entirely up to the entity controlling RD2 if they for some reason want to
> enforce the policy of the entity controlling AD2. So I see no reason
> whatsoever why symmetry is required.
>
> Policy is not decided and enforced by the AD, the RD or any service
> connected with them, it is decided and enforced by the entities behind them.
> If the same entity controls an AD and a RD, then it's meaningless to try to
> divide up that entity's policy into AD policy and RD policy, because it can
> enforce that policy at any level, type of domain or connected service it
> controls.
>
> But, like you, I am totally in favor of letting the entity controlling the
> destination RD decide policy once the agent is there. However, if the
> agent's own AD for some reason wants to stop the agent from going there,
> then I think it should have the possibility to do so. In all honesty, I
> don't think an AD imposing undue restrictions on where people are allowed to
> go or what they are allowed to do there will survive for long though, once
> competition is in place. You may have to start out fresh, with a new AD,
> without the assets and inventory connected to the old AD, but I think most
> people are willing to take that step if they feel their freedom is too
> limited.
>
> Best regards,
>
> Magnus
>
>
> -----Ursprungligt meddelande-----
> Från: Morgaine [mailto:[e-mail]]
> Skickat: den 8 oktober 2009 11:42
> Till: Magnus Zeisig
> Kopia: [e-mail]
> Ämne: Re: [ogpx] Protocol for permitting policy decisions
>
> Magnus,
>
> If ADs are involved in region policy, then in the multi-world deployment
> pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to
> RD2, because AD2 will be involved in region policy too.  It's symmetric with
> AD1.
>
> This is what Joshua wanted to avoid, and it can only be avoided by not
> giving ADs policy control over regions, otherwise symmetry requires that AD2
> be consulted as well.
>
> It's this kind of problem that reinforces what David's been saying about
> the right mess we currently have when talking about domains determining
> policy.  The AD/RD split was reasonably adequate when OGP was only extending
> a single world with policy-free regions, but it is insufficient to do a good
> job once we get into multi-world deployments with more complex service and
> policy patterns which require much more flexibility.
>
>
> Morgaine.
>
>
>
>
> ==================================
>
>
> On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig <[e-mail]>
> wrote:
>
>
>
>        -----BEGIN PGP SIGNED MESSAGE-----
>        Hash: SHA256
>
>        I am strongly in favour of leaving policy descisions to the RD, but
> since there seems to be a need for at least some AD managers to be able to
> make policy decisions as well, I guess the protocol handshake need even more
> flexibility than the versions scetched on by Meadhbh, Carlo and me so far. I
> will adapt the diagram style of Meadhbh and Carlo (
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html), since
> it's more readable than my text-flow variant. Also, I will leave out
> parameter examples since there seem to be a risk people get hooked on if a
> certain parameter should be included or not, rather than the possibility of
> handling any parameter.
>
>        I may be paranoid, but I still prefer agent domains to be allowed,
> but not forced by protocol, to reduce the dissemination of information about
> their clients as far as possible, and there Carlo's AND version in the
> response is a good step forward (
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We might
> even wind up with negotiations where one domain requests the actual values
> while the other domain only wants to disseminate a reply to if it fits a
> range for one or more of the requested parameters.
>
>        AD -------------------------(name, <RDkey1?,
> RDkey2?>)------------------------> RD
>        AD <--(name, <RDvalue1, RDvalue2, ADkey1?, ADkey2?, agentkey1?,
> agentkey2?>)--- RD
>        AD --(name, <RDvalues OK, ADvalue1, ADvalue2, agentvalue1, agentkey2
> range?>)-> RD
>        AD <----------(name, <ADvalues OK, agentvalue1 OK, agentkey2
> range>)----------- RD
>        AD ----------------------------(name, agentkey2
> OK)---------------------------> RD
>        AD <-----------------------------(name, rez
> cap)------------------------------- RD
>
>        In this example, RD might have refused giving the required range for
> agentvalue2, either because it technically doesn't support that kind of
> negotiation or because of policy, in either case of which the rez cap would
> have failed. It might on the other hand instead already from the beginning
> have supplied the required ranges instead of asking for the actual value. I
> think it would be good if the protocol would enable either of these cases
> for maximum flexibility.
>
>        It may also be an idea to permit caching of at least AD- and
> RD-parameters or evaluations of them, especially if we're talking extensive
> sets with perhaps hundreds of parameters. Since the ADs and RDs should be
> free to update their own parameters at any time, the handshake in that case
> must of course contain a check if cached parameters have been updated. Also,
> if an AD or RD supports several sets of parameters depending on which domain
> or service it deals with, means to distinguish between them are required,
> perhaps using policy URI's the way Meadhbh suggested (
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A policy
> could then basically be broken down into a set of own parameter values and
> required parameter ranges for the domain or service connecting.
>
>        I also think, like Meadhbh (
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that we
> will need to suggest, but not require, a number of parameter name and
> formats to facilitate communication, so that not e.g. US and UK domains
> can't connect, because one asks about "color" and the other one only can
> respond about "colour".
>
>        Best regards,
>
>        Magnus
>
>
>        - -----Ursprungligt meddelande-----
>        Från: Carlo Wood [mailto:[e-mail]]
>        Skickat: den 7 oktober 2009 22:36
>        Till: Infinity Linden
>        Kopia: Magnus Zeisig; [e-mail]
>        Ämne: Re: [ogpx] Protocol for permitting policy decisions
>
>        On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote:
>        > option 3: multi-message handshake
>        >
>        > AD --------------- (name) -------------> RD
>        > AD <-------- (X, age > X? cap) --------- RD
>        >
>        > AD ------------------------------------> RD (age > X? cap)
>        > AD <------------ (rez cap) ------------- RD
>
>        Note, again, the need for a flexible protocol negotiation:
>        we can't know, already, what all will be needed.
>
>        Nevertheless, the more flexibility the better imho.
>        I'd prefer to see this:
>
>        AD ------(name, <list with keywords>) -----------> RD
>        AD <-----(name, <list with keywords + ranges>) --- RD
>        AD ------(name, yes/no)--------------------------> RD
>        AD <-----(rez cap) ------------------------------- RD
>
>        Where VWRAP will not define what keywords are possible.
>
>        However, implementers might, for example, choose to use 'AGE' as
> keyword
>        with an integer range, leading to a msg exchange like
>
>        AD ------(name, (AGE)) -----------> RD
>        AD <-----(name, (AGE, 21)) -------- RD
>        AD ------(name, yes)--------------> RD
>        AD <-----(rez cap) ---------------- RD
>
>        or some might implement
>
>        AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
>        AD <-----(name, (AGE, 13), YES) ------------------ RD
>        AD ------(name, yes, yes)------------------------> RD
>        AD <-----(rez cap) ------------------------------- RD
>
>        For privacy reasons, I think it would suffice to
>        just send the AND of all 'yes's, thus:
>
>        AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
>        AD <-----(name, (AGE, 13), YES) ------------------ RD
>        AD ------(name, yes)-----------------------------> RD
>        AD <-----(rez cap) ------------------------------- RD
>
>        or,
>
>        AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
>        AD <-----(name, (AGE, 13), DONTCARE) ------------- RD
>        AD ------(name, yes)-----------------------------> RD
>        AD <-----(rez cap) ------------------------------- RD
>
>        Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined by us,
>        but we would define how to handle integer ranges, booleans,
>        don't cares, string literals, and perhaps regular expressions.
>
>        - --
>        Carlo Wood <[e-mail]>
>
>        -----BEGIN PGP SIGNATURE-----
>        Version: 9.8.3 (Build 4028)
>        Charset: utf-8
>
>        wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL
>        JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/
>        cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ
>        RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm
>        tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd
>        60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w==
>        =2NSu
>        -----END PGP SIGNATURE-----
>
>
>
>        _______________________________________________
>        ogpx mailing list
>        [e-mail]
>        https://www.ietf.org/mailman/listinfo/ogpx
>
>
>
>
>