Hi - I'm noticing some issues with terminology that are tending to make discussion about the topic difficult. For example " rollover" is actually the monolithic combination of a number of discrete actions. Let me suggest we try hard to talk about the discrete actions rather than "rollover" as it will make our life a bit easier in figuring out timing, resources and plans. Here's my break down. This assumes that we eventually get to a steady state of at least two trust anchors; that 5011 is used; and that the other mechanisms have sufficient assurances to them that providing them does not adversely affect the security model for DNSSEC. Note that nowhere below discusses the time lines necessary for the discrete actions due to the current root signing processes (eg scheduling and travel time). Trust anchor actions (from zone owner point of view): add trust anchor generate a key pair publish via 5011 format the trust point DNSKEY RRSet sign the trust point DNSKEY RRSet with an existing trust anchor private key publish the signed DNSKEY RRSet via DNS for twice the add hold down period publish via ICANN web page format the XML trust anchor record update the web page publicize the update (for those doing manual updates) publish via software vendors sign the new trust anchor set with an as yet to be determined ICANN credential send trust anchor set to vendors publicize the update and participating vendors publicize the update and participating vendors publicize the update and participating vendors publicize the update and participating vendors return to normal signing policies (e.g. 1 key signs DNSKEY RRSet, stand by key(s) present or not present) after a minimum of twice the add hold down time; additional time may be needed to allow keys to propogate through vendor and manual processes. revoke trust anchor set revoke bit on key to be revoked format the trust point DNSKEY RRSet sign the trust point DNSKEY RRSet with both a still valid trust anchor key and the private key being revoked publish the signed DNSKEY RRSet via DNS for twice the remove hold down period or longer. update the ICANN web page list of trust anchors update the signed trust anchor set for vendors send the updated signed trust anchor set to the vendors publicize the revocation [[ level of effort for this action depends on whether revocation was due to compromise or routine supercession actions]] supercede a key [ two stage] add a trust anchor wait for completion of add revoke an old trust anchor return to normal signing procedures after twice the removal time emergency revocation without immediate supercession (assumes 2 or more keys, of which at least N-1 keys are not compromised) [[ Same actions as "revoke trust anchor"]] [[ In the model below, for non emergency supercessions, the publish to the icann web page and publish to the vendor channel can be moved ahead of 5011 in the time line and a delay imposed between. However, the semantics which describe the TA (icann xml, signed TAs for vendors) will need to be rich enough to describe future events as the revocation won't necessarily have occurred when the update data reaches the end user; there's also the question of what happens if a compromise occurs between the ICANN/Vendor publish and the effective date]] supercede a key [ one stage ] aka emergency or non-emergency revocation with immediate supercession (assumes 1 compromised or superceded key and at least 1 non compromised key, can scale to more than 1 compromised key) generate a key pair set revoke bit on key to be revoked publish via 5011 format the trust point DNSKEY RRSet to include both revoked key and new public key sign the trust point DNSKEY RRSet with both the revoked key and a different valid trust anchor private key publish the signed DNSKEY RRSet via DNS for the greater of twice the hold down period or twice the removal period publish via the ICANN web page format the XML trust anchor object to add the new trust anchor and remove the old publish the new object on the ICANN web page publicize the change publish via the Vendor channel sign the revised trust anchor set send the signed set to the participating vendors have them publicize to their own customers (customers will have also seen the above announcement). return to normal signing procedures after the greater of twice the hold down period or twice the removal period; can be extended to allow for more time for completion of web page and vendor channel updates. trust reboot [compromise] [[ publicize the compromise - may be deferred if impact assessment dictates]] generate new key pairs publish via the ICANN web page format the XML trust anchor object (containing only the new trust anchors) publish the new object on the ICANN web page publish via the vendor channel sign the revised trust anchor set (containing only the new trust anchors) send the signed set to the participating vendors wait 30 days publicize the compromise and updates wait 60 more days revoke all the compromised trust anchors via 5011 root DNSKEY RRSet will include old trust anchors as well as new trust anchor and will be signed by new trust anchor as well as old. wait twice the remove hold down time resume normal signing procedures trust reboot [ routine ] generate new key pairs do 5011 add of the new trust anchors publish via the ICANN web page format the XML trust anchor object (containing old AND new trust anchors) publish the new object on the ICANN web page publish via the vendor channel sign the revised trust anchor set (containing old AND new trust anchors) send the signed set to the participating vendors publicize the compromise and updates wait 60 days at least revoke all the old trust anchors via 5011 wait twice the remove hold down time resume normal signing procedures