Re: [ogpx] Protocol for permitting policy decisions

[Morgaine <[e-mail]>]

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] <[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
>
>