Tim April <timapril@gmail.com> wrote: > The rotation period of five years, in my opinion, is far too long and > can result in operators and developers becoming complacent, or being > generally unaware, that keys rolls happen. My current opinion is that > the rotation period should be roughly once a year. The yearly cadence > would allow the key to be somewhat stable but also have the key rolls > be a regular event that can be predicted while not falling too far out > of working memory. I understood that there was some root zone maintenance times that meant that changes had to happen on the 11th or something of Jan/May/July/Sept, or some such. Otherwise, I like the concept of your schedule. It's a bit US centric in terms of bank holidays, etc, but I'm sure that the exact exclusion list (as you suggest) can worked out. > The current steady state of the KSK has one valid KSK. To this point, > this has not been a problem, but this also means that if an emergency > keyroll is required, the current tooling / support will not help with a > roll. A potential way to support an emergency key roll, should one be > needed, would be to have a backup key created and staged in the root > zone. I think that this is an important thing to consider, but I think that we need to think more about what kinds of emergencies it deals with, and which kind still cause a failure. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-