Re: [ogpx] Protocol for permitting policy decisions

[Magnus Zeisig <[e-mail]>]

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