[Opendnssec-develop] Enforcer engine design v2 work breakdown

[Yuri Schaeffer]

A status update:

I'm happy to tell I made some good progress with the rules. I've
introduced a bunch of likely rollovers to my prototype which all roll as
expected as far as I can tell. Next thing I will do is update the
document with the changed rules and add a better explanation. Than start
coding again. I asked Matthijs to review the output of the prototype. 

Aside the dnssec validity rules the are some policy issues coming to the
surface the past days. 

The main problem is that policy information is not tied to a key (in my
initial design it was but this was somehow dropped by Rene and me in the
actual implementation as redundant). When a policy changes all existing
keys should still propagate according to the old policy. This is fixable
after Rene's vacation. (I will not block on this)

The other thing that *might* be a problem is that the algorithm
implicitly assumes you'll want to have only one key of each role. It
will not keep juggling two ZSKs if one is enough to validate. I worked
out a rough idea for a fix with Matthijs. It requires no changes from
Rene but it's non-trivial. Therefore I want to know whether or not we
want to support this. Is there a usecase? There is not much
code-dependency so changing this at a later time will not increase
required work.

> - Explain (and find out) why these rules are valid *and* sound.

My understanding grows. Expect better fundament of these rules soon.

> - Work out how to apply the 'minimize flags' to achieve different
> rollover strategies. Must be better than gut feeling.

This works. The flags are evaluated in the 'policy step'. TODO:
introduces exceptions when to ignore the roll strategies. (e.g. you
can't do dnskey prepublication on a algorithm rollover)

> - Work out how a 5011 rollover would work in this model _exactly_.

Moved to the bottom of the priority list.

> - Formulate a rule that prevents the RRSIG DNSKEY to transition quicker
> than the actual DNSKEY.

I did (and introduced an ordening) and dropped it again. This is now a
policy decision, not reflected in the rules.

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

Don't know yet. How about a policy with no keys?

//yuri