diff --git a/DNSSEC-Key-and-Signing-Policy-(KASP).md b/DNSSEC-Key-and-Signing-Policy-(KASP).md
index 086c323..cd8ab05 100644
--- a/DNSSEC-Key-and-Signing-Policy-(KASP).md
+++ b/DNSSEC-Key-and-Signing-Policy-(KASP).md
@@ -69,3 +69,209 @@ is set for a zone.
    unsigned zones.  This is also no longer needed when KASP is introduced
    because when setting a `dnssec-policy` for a secondary zone this indicates
    that `inline-signing` is desired.
+
+1. `max-zone-ttl`: This will cap all TTLs in a zone file to the specified
+   value. Although this option may be used for non-DNSSEC zones, it is really
+   only useful for DNSSEC-signed zones because when performing key rollovers
+   the timing depends on the largest TTL in the zone.  The value set in the
+   `dnssec-policy` statement will override the existing `max-zone-ttl` value.
+
+1. `sig-signing-nodes`: This specifies the number of nodes to be examined
+   in a quantum when signing a zone with a new DNSKEY.  This presumable is
+   to avoid keeping the database connection open for a long time.  With the
+   current database approach this probably needs to stay.
+
+1. `sig-signing-signatures`: This specifies a threshold number of how many
+   signatures will be generated in a quantum.  Similar to `sig-signing-nodes`.
+
+1. `sig-signing-type`: Internal record type number, used to track zone
+   signing process.  This likely will go away in favor of a new method.
+
+1. `sig-validity-interval`: Specifies the number of days a signature is valid.
+   The second optional value is the refresh interval. Thos option will
+   be replaced by KASP configuration values "signatures-validity" and
+   "signatures-refresh".
+
+1. `update-check-ksk`: When set to "no", KSK will also sign non-DNSKEY RRsets.
+   This option will go away and key roles will be used to determine what
+   keys sign which RRsets (A KSK that should sign all RRsets will have both
+   the KSK and ZSK role and is referred to as a CSK).
+
+Other DNSSEC related configuration options that are not related to the policy
+are likely to stay:
+
+
+1. `key-directory`: This is where the DNSKEY key files can be found.
+
+1. `serial-update-method`: This is used for dynamic zones to determne how
+   the SOA SERIAL should be updated.  There will likely be a separate
+   configuration option for the serial update method when resigning a zone.
+
+# KASP Configuration
+
+The KASP Configuration may look something like the example configuration
+below. This includes all options as described in the KASP draft, but we may
+decide that some options are not required.
+
+```
+dnssec-policy "nsec3" {
+
+    description "policy for zones that require zone walking mitigation";
+
+    // Signatures
+    signatures-resign PT2H;
+    signatures-refresh P3D;
+    signatures-validity P14D;
+    signatures-validity-dnskey P14D;
+    signatures-validity-denial P7D;
+    signatures-jitter PT12H;
+    signatures-inception-offset PT300S;
+
+    // Denial of existence
+    denial-type nsec3;
+    nsec3param-ttl 0;
+    nsec3-optout no;
+    nsec3-hash-algorithm 1;
+    nsec3-hash-iterations 5;
+    nsec3-salt-length 8;
+    nsec3-resalt P100D;
+
+    // Keys
+    dnskey-ttl 3600;
+    dnskey-publish-safety PT3600S;
+    dnskey-retire-safety PT3600S;
+    share-keys no;
+    purge-keys-after P14D;
+
+    keys {
+        ksk hsm "softhsm" P5Y ECDSAP256SHA256;
+        zsk directory "/etc/bind9/dnsseckeys/" P30D ECDSAP256SHA256;
+        csk key-directory PT0S 8 2048;
+    };
+
+    // Parent synchronization
+    cds yes;
+    cdnskey yes;
+    check-ds { 127.0.0.53; };
+    check-ds-interval PT3600S;
+
+    // Zone properties
+    zone-propagation-delay PT3600S;
+    zone-soa-ttl 3600;
+    zone-soa-minimum 3600;
+    zone-soa-serial-update-method unixtime;
+    zone-max-ttl 24H;
+
+    // Parent properties
+    parent-propagation-delay PT24H;
+    parent-ds-ttl 3600;
+    parent-soa-ttl 3600;
+    parent-soa-minimum 3600;
+};
+```
+
+# KASP design
+
+## dnssec-policy versus dnssec-keymgr
+
+Key management in BIND 9 is currently implemented with a Python script
+called `dnssec-keymgr`. It uses the DNSSEC tools for manipulating DNSSEC key
+metadata.
+
+With `dnssec-policy` configured in `named.conf` you no longer need to manually
+call `dnssec-keymgr` or the tools it wraps around, `dnssec-keygen` and
+`dnssec-settime` (although it is still possible to use them). The policy in
+`named.conf` will make `named` create keys when necessary and set the key
+timings accordingly.
+
+## Key roles
+
+With BIND 9 you can sign your zones with a Zone Signing Key (ZSK) and a
+Key Signing Key (KSK). If you provide only one key, the zone will be signed
+with just one key (effectively acting as a Combined Signing Key (CSK). If
+one of the keys is offline, BIND 9 will temporarily change the key usage: A
+KSK may sign DNSKEY unrelated RRsets.
+
+ZSKs by default sign the complete zone, except when `dnssec-dnskey-kskonly`
+and `update-check-ksk` are both set to `yes`.
+
+KASP introduces key roles making key usage more explicit, without depending
+on state of the keys or additional configuration values. A key that has the
+KSK role will always sign only DNSKEY related RRsets, and a key with a ZSK role
+will always sign only DNSKEY unrelated RRsets. A key can have both roles, which
+is referred to as a CSK. Below is an example configuration for the three types
+of keys:
+```
+        keys {
+                ksk hsm "softhsm" P5Y ECDSAP256SHA256;
+                zsk directory "/etc/bind9/dnsseckeys/" P30D ECDSAP256SHA256;
+                csk key-directory PT0S 8 2048;
+        };
+```
+
+## NSEC3
+
+Currently if you want to sign your zone with NSEC3 you can do so by introducing
+an NSEC3PARAM record via Dynamic Update. This is no longer necessary with
+`dnssec-policy` as you can configure NSEC3 usage in `named.conf`.
+
+## Changing policies
+
+You can change a zone's policy by referring to a different `dnssec-policy`
+or by changing the `dnssec-policy` itself. After a reload of the configuration
+key timings may be adjusted. This may trigger a key rollover (for example if
+the key lifetimes have been shortened, or if other key properties have changed.
+
+## Key state machines
+
+Rollover correctness are guaranteed by key state machines. See for more
+information:
+
+    https://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf
+
+# Requirements
+
+## Configuration
+
+1. You can configure DNSSEC for a zone with a single configuration option (`dnssec-policy _default`).
+
+1. You can configure DNSSEC for a zone manually (`dnssec-policy` statement).
+
+1. No human interaction is needed, `named` will take care of key and signature management.
+
+## Key generation
+
+1.A You can create keys in advance with `dnssec-keygen`
+1.B When a zone with a DNSSEC policy set has no keys, `named` will create keys on the fly.
+1.C A zone with a DNSSEC policy set that has keys configured that does not match the policy will have those keys become retired and a new set of keys will be selected or created.
+1.D When the key is created, the key is in "Generated" state (no other key timings are set).
+
+## Key publication
+
+1.A The first time the zone is signed, the zone will include all the necessary RRSIG and DNSKEY records.
+1.B When a key is added to the zone, the zone is in "Published" state (The "published" key timing is set to now or a past time).
+
+## Key activation
+
+1.A When the key is published long enough (publication interval has passed), the zone is also in "Active" state (Meaning "active" key timing is set).
+1.B When a key is activated and has a lifetime configured, the "retired" key timing must be set to the "active" plus its lifetime.
+1.C A key that has the KSK role will always sign DNSKEY related RRsets.
+
+## Key rollover
+
+1.A A successor key must be created before the predecessor key will retire.
+1.B A successor key will have its "Published" state set in the future (lifetime - publication interval).
+
+## Key retirement
+
+1.A Keys that are retired will no longer be used to create new signatures, but existing signatures may be reused until they are close to expiring.
+1.B Retired keys will have "retired" key timing set to now or a past time.
+
+## Key removal
+
+1.A A key that has no signatures left in the zone, and the retire interval has passed are removed from the zone.
+1.B A removed key has the "removed" key timing set to now or a past time.
+
+## Key purging
+
+1.A Removed keys may be purged from storage.
\ No newline at end of file