With respect to scale, I still need some more thoughtful insight to justify your claim. Having each of the clients (e.g. 1000 PEPs each making 10 calls on a single PDP a second) get and supply the information to a PDP that has to do 10,000 decisions a second, scales far better than putting all the work on the PDP and making it perform remote calls to a data repository for each access decision. Sorry for getting back on this discussion, I should probably just give up : but t hat example is wrong. Once you have any single master data repository - RDBMS most likely, or some local image of it, having as close consumer as possible is preferrable. And PDP is much more likely to be local - same machine/subnet - even running on top of a database in some cases then multitude of distributed clients. I am suggesting scaling/clustering PDPs as needed, and cutting down on remote queries and traffic. That's why people have stored procedures, is not it? Other example would be a PDP running alongside a directory server. Should clients access relevant data indepently, then resend it along with the request to PDP - or is it faster to access it locally? Also - client may not know what information is relevant. If you have 100 different actions. For each action some information is needed to evaluated - as described in the rule - should PEP prepare and send ALL potentially avalaible data along with the request - or PDP will retrive just the relevant one during the rule evaluation? I think the second case is far more preferrable - PEP has no information about rules, and can not optimise it. Thus supplying information along with the request may scale O(N), as you add actions, and O(1), if data is retrieved locally.. And to effectiv e ly cluster PDPs, provisions for error handling in protocol seem to be essential. Daniel.