Re: [ogpx] Protocol for permitting policy decisions

[Magnus Zeisig <[e-mail]>]

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