Re: [ogpx] Protocol for permitting policy decisions

[Magnus Zeisig <[e-mail]>]

Morgain, I believe we're not that far off from each other, even if I think the example you presented was not appropriate and I still can see no reason for your symmetry in AD/RD requests. The latter notion has already been commented upon by others in more detail. But like you, I also think it's reasonable to leave or generalize away from the thought of domains and rather use services as protocol endpoints. Regardless of if we talk about domains or services, I think the basic negotiation pattern will always be the same:

Client: I want your services but (may) have some (policy) demands to use them.
Server/Service: I offer you my services but (may) have some (policy) demands to let you use them.

Both client and server/service can be the agent or region domain, user/agent, authentication, presence, asset, inventory, simulation, voice or movie service, or any other domain or service you can think of, standalone or clustered in any combinations depending on technical issues, ownership and agreements.

So, when any client (C) requests any service from a server/service (S), it may look like this, if all work out:
C ---(id, service?, S policy?)--> S
C <--(id, S policy, C policy?)--- S
C --(id, S policy OK, C policy)-> S
C <-(id, C policy OK, service)--- S

Policies in this case may refer both to things like data format (mesh format, image format) and data classification (adult, require IP agreements). The acceptance of policies, permitting the service performed, from both C and S, may be negotiated directly between C and S, or between servers/services connected to C and S respectively, negotiated at the time of service request and/or stored in some form of access, token or cap, at C and/or S respectively, or servers/services connected to them.

If C and S are controlled by the same entity, that entity may use any way, including VWRAP, to negotiate and deliver the service, and the policy part may be left out from the negotiation, e.g. because the entity use the same policy for all services controlled.

If C and S are controlled by different entities, those entities may use any way, including VWRAP, to negotiate and deliver the service, and the policy part may be left out from the negotiation, e.g. because the entities have an already established agreement (format agreement, domain of trust) or don't require one.

If the policy negotiation is left out, the request becomes:
C --(id, service?)-> S
C <-(id, service)--- S

To support a flexible new infrastructure with many different domains or services interacting in many different constellations, including interop between the "classical" virtual worlds of today, VWRAP should be able to treat any service request and/or policy negotiation the same or very similar, regardless of endpoints and endpoint types. The endpoints will mutually decide if to use VWRAP and to which extent. VWRAP should however be an attractive enough way to handle the communication to be a first hand choice, both between clients and servers/services of the same as well as different entities. One advantage of using VWRAP will then be that outsourcing, exchange or addition of services will be easy, since basically just addresses of servers/services will need to be changed and transfer of old data to the new services be performed.

I know that some of the things above have already been stated on the list, but I'm repeating them just for the clarity of argumentation.

Best regards,

Magnus


-----Ursprungligt meddelande-----
Från: Morgaine [mailto:[e-mail]]
Skickat: den 8 oktober 2009 14:32
Till: Magnus Zeisig
Kopia: [e-mail]
Ämne: Re: [ogpx] Protocol for permitting policy decisions

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