[Opendnssec-develop] Enforcer engine design v2 work breakdown

[Yuri Schaeffer]

Hi everyone,

In the teleconference about the enforcer this morning I was asked to
provide a breakdown of the work I think is necessary to switch to the
proposed model. This is it. Note that there are some extra points which
are not explicit in the requirements but are on the wish list for the
future (Such as 5011). I feel support for this should be done correctly
from the start, even when not providing an interface to the user for it
-yet-.

Document
--------
- The current document is very rudimentary and needs to explain the
algorithm more clear (and should use more natural language rather than
text!).
- Merge the previous document in this one "Roland: One document to rule
them all", keep the old one as reference.
- Improve notation (e.g. include signing algorithm in it)
- Work out the scenarios for a couple of different rollovers as
examples. This is also useful for Nick at a later stage of testing.
- Explain (and find out) why these rules are valid *and* sound.

Theory
---------
- Work out how to apply the 'minimize flags' to achieve different
rollover strategies. Must be better than gut feeling.
- Work out how a 5011 rollover would work in this model _exactly_.
- Formulate a rule that prevents the RRSIG DNSKEY to transition quicker
than the actual DNSKEY.
- Work out how 'normal' standby keys are supposed to work.

Code
-------------
- Figure out how the user indicates which rollover strategy it wants in
the kasp.xml (input request for all of you). 
- Replace the decision mechanism in the current enforcer-ng code.
- Introduce a function $f(x, y, p): t$ which indicates how much time a
record should at least spend in state x before transitioning to state y
given policy p. (This is currently very much intertwined in the
TransitionDecisionMechanism :-O )
- Introduce a state for the RRSIG DNSKEY in the database and interface
to the rest of the enforcer. (Rene already did this if I'm correct!)
- Figure out how the user should indicate that an insecure zone is okay
to have. How does this policy look like? (again, input request for all
of you)

regards,
Yuri