Policy definition by Guus Sliepen.
This document is closely related to Arie Taal's document:
http://www.ietf.org/internet-drafts/draft-taal-aaaarch-generic-pol-00.txt

AVPS
----

Attribute value pairs are the basic element for information exchange. They are
composed of a name, which is a way to address them, and a value, which is the
actual information.

<attribute value pair>	= (<variable type>, <name>, <value>)

<name>			= <character string>

<variable type>		= AVP | ASM | LDAP | SQL | SNMP | POLICY

<value>			= anything

If the variable type is AVP, then the complete AVP is something that only
resides in the AAA Server and does not have to be stored elsewhere. Name is the
identifier for the AVP.

If the type is POLICY, then the value of the AVP is a Local Policy that is meant
to be pushed into the policy repository, under the given name. Whether this
policy may be pushed depends on the policy that is evaluating this AVP, or maybe
some meta-policy that governs the pushing of policies into the repository.

If the type is anything else, then name does not necessarily have to be a single
identifier for a variable. For example in the case of type SQL, name will likely
be (part of) an SQL query.

The value of an attribute value pair may consist of multiple parts or be
structured.

REQUESTS
--------

Requests in AAA can invoke a Local or Remote Policy, let it evaluate, and get
the result of that evaluation. Requests therefore have two or more parameters.

<request>		= (<address>, <policy name>, [<attribute value pair>...])

The result of a request should at least include a boolean or another type of
result that indicates the status of the evaluation, and possibly other
attribute value pairs.

POLICIES
--------

Policies are logical expressions which attach actions to the result of the
conditions that are to be evaluated. Conditions can be anything that is
computable. Actions are represented as AVPs.

<policy>		= (<computed expression>)

<computed expression>	= (<computed value> -> <action>)

<computed value>	= <constant> | <free variable> |
                          <request> | <predicate>

<free variable>		= (<variable type>, <name>)

<predicate>		= <computed expression> |
			  <unary operator><computed expression> |
			  <computed expression><binary operator><computed expression>

[Main differences with Arie Taal's definition:

- Since operators can also be boolean operators, there is no need for an
  explicit DNF notation, therefore the notion of conditions and terms has been
  dropped.

- Predicates can be recursive, allowing (almost?) any expression

- Local and remote policy references are represented by requests
]

The symbol "->" means that if the left term is true, then the right term is
evaluated/executed, otherwise it will not. The result of a -> b is a. This also
allows multiple actions to be associated with a single computed value:

a -> b -> c -> d -> ...

Here, all the actions b, c, d and so on will be executed if a is true.

ACTIONS
-------

The following definition might be a bit questionable:

<action>		= <returnable attribute value pair> |
			  <executable attribute value pair> |
                          <computed expression>

Since policies should be able to return some information besides a boolean true
or false, the returnable AVP is an AVP that is sent back to the application
sending the request.

To actually do something physical, executable AVPs are AVPs that are directly
executed, which means that the value of the AVP is stored in the "address". The
address is made up of the variable type and the name. So, if the variable type
is SQL, then name can contain part of the query and value can contain the data
that is to be stored into the SQL database. If another application or device
reads this information from the database and uses it to control something, then
an action can drive a PDP in this way.

The last term in the definition is questionable, but I added it because possibly
we might want out action to be to send out a request, or to make another
decission and do some actions because of that. Although this can all be done
without it being in the action, it might simplify things a lot, but there is
also a real difference: the result of an action is not used in any way.

OPERATORS
---------

Unary and binary operators can be anything that can also be found in most
programming languages, for example C. The only exception is any operator that
changes the variable on which it works (like pre or post increment and
decrement). Due to the definition above, the expressions are implicitly
parenthesized.

There are some binary boolean operators however, like "or" and "and", for which
most programming language define that they are cascading, which means that if
the left term already determines the result of the operation, the right term is
not evaluated any more. This has some implications for policies, because terms
there are computed expressions, which have actions associated with them. It
might be that we have an "and" operation and whether or not the result is false
or not, we want the action of each true term to be executed. If that is so, we
might also be interested in letting both terms be evaluated at the same time,
because this will probably decrease the latency of evaluating this policy. This
calls for three variants of "and":

- Cascading "and": evaluate left term, if true then evaluate right term, else
  stop.
- Serial "and": evaluate left term, then evaluate right term.
- Parallel "and": evaluate left term and right term simultaneously.

The same goes for the "or" operator. Other operators like "xor" (exclusive "or")
and "eqv" (negated "xor") always have to evaluate both sides. For those, two
variants should be defined, a serial and a parallel one.

Another issue, which is handled invisibly by most programming language, is
promotion or automatic casting when an operator is used on variables of
different types. To keep things sane it might be wise to disallow this, but to
provide unary operators which cast variables of one type to another.