[ksk-change] Capabilities of validating systems we need to consider

Olaf Kolkman kolkman at isoc.org
Mon Sep 22 07:27:23 UTC 2014


On Sep 21, 2014, at 5:27 PM, Paul Hoffman <paul.hoffman at vpnc.org<mailto:paul.hoffman at vpnc.org>> wrote:

Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:

1) Able to automatically pull and correctly use a new KSK

2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention

3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK

Are there other categories that would look operationally different to either customers of the system or to operators of signed zones?



Perhaps there are instances that do leap-off fait type of configurations but I am not aware of them.

Also the systems that have a to long off-line shelf life to be able to do a RFC5011 type rollover. They would be in (1) if they’d be on during the rollover but because of their off-lineness they might find themselves in cat. (2).

I argue that we ignore category (3). If we allow ourselves to be ossified by that type of mistake we will never be able to roll. In fact the argument for roll early and often is to make sure to weed out all existence of (3) and make category (2) aware that they will need to pay attention.



—Olaf



——————————
Olaf Kolkman
Internet Society
Chief Internet Technology Officer
kolkman at isoc.org<mailto:kolkman at isoc.org>  www.isoc.org<http://www.isoc.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20140922/6af4a11e/attachment.html>


More information about the ksk-rollover mailing list