== RPZone Ordering ==

A generic recommenedation for zone ordering as listed in the
response policy definition for a resolver is presented.

The terms 'white list' and 'block list' are used to refer to
RPZones with the normal meaning (white does full recursion,
block does something else, as specified in the policy
statement).

Organisations using RPZ may have numerous external reputation
data providers, which may provide both white and block lists.
Additionally, the organisation may have local white lists
and/or local test and/or block lists.

Locally defined zones are useful.  White lists prevent eager
reputation providers blocking things that one wishes to never
be blocked, and local block lists allow rapid dynamic responses
to things like phishing attacks.

Where multiple external providers are used, this proposal
makes no recommendation about which provider should come
before another.

There may end up being many zones.  This raises an issue of 
a potential zone naming convention, but that is outside the 
scope of this discussion.

The proposed zone ordering recommendation is:

* local white list(s)
* local test block list(s)
* for each external reputation provider, their white list(s)
  and then block lists(s).  The sequence of each white or block
  list, if there are multiple, is their recommendation.
* local block list(s)

For example, say that we have a single local white (white.local), 
and single local test block (test.block.local) and single local
block (block.local), and that there are two external providers,
X and Y, as:

* X, with one white (white.X) and one block (block.X), and 
* Y, with one white (white.Y) and two block (mary.block.Y and bob.block.Y)

Also assume that organisation Y recommends that mary is listed before bob.

The recommendation would be:

* white.local
* test.block.local
* white.X
* block.X
* white.Y
* mary.block.Y
* bob.block.Y
* block.local

The rationale is:

* local white must come first (fairly obvious)
* local test block should be next (to enable testing not being 
  confused with other block lists)
* each reputation providers lists need to be grouped into white
  and then block, rather than grouping all the whites and then
  the blocks, as this preserves the intention of the reputation
  provider.  E.g Two reputation providers may list the same entry,
  one in white and the other in block.  If all whites are first
  then the provider with the block entry has no chance block.
* local block should be last.  Thus, when one see's an entry in
  one's local block being hit earlier by an external provider,
  one knows that they have absorbed the threat into their data.

Hugo Connery, with input from April Lorenzen, 2013-07