We have reviewed the plan for continuing the root ksk rollover published by ICANN. We think the proposed schedule is fine and the reasoning behind it is sensible. We think that the data you have collected relating to RFC 8145 provides no clear evidence of widespread negative outcomes for end-users when signatures by KSK-2010 are removed. We suggest that you go right ahead. We are aware of another idea that might be of use: it's not our idea, but we've heard it from various places and think it's worth mentioning. If a future KSK rollover was structured as an algorithm roll to a desirable new algorithm that would benefit from wider implementation, validators that didn't support the new algorithm would fail open (go insecure) rather than failing closed (go dark), regardless of whether they had managed to update their local trust anchor with the new KSK (see RFC 4035 section 4.2 and RFC 6840 section 5.2). This approach might have the dual attractive qualities that the worst-case end-user impact would be a lack of validation rather than a failure to validate and also that it would encourage deployment of algorithms like ECDSA (RFC 6605) that have smaller keys and signatures. Something to think about for the future, perhaps. Bill Snow Snake Hill Labs