<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Sep 22, 2014, at 4:29 PM, David Conrad <<a href="mailto:david.conrad@icann.org" class="">david.conrad@icann.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">"(a)
there is no operational reason that forces the key to change, (b) there is a risk no matter how slight that we might screw up, (c) it is expensive and time consuming to drag the necessary people into the secure facilities to spend the 2+ hours necessary
to do the key handling appropriately, and (d), it is likely that rolling the key _will_ break things, the only question is how much and who will be affected.</span></div>
</blockquote>
<br class="">
</div>
<div><br class="">
</div>
<div>I believe that the argument to roll to make sure bad operational habits are not ossified (paraphrased from RFC6771) is an operational reason (Ive pasted it below for reference). So I do not (fully) agree with (a). I would agree if you would say inherit
operational reason.</div>
<div><br class="">
</div>
<div>The question is really what sort of breakage (and associated costs) do we accept now versus when we do have an inherit operational reason. I believe, but that is not very helpful I realize, that by accepting some breakage today (mainly accepting (d)) we
will reduce the fraction of folk that suffer (d) in the future. At some point that argument will not hold because the amount of people in the (d) category are to many or more than only a number of early deployers that still track the technology developments.</div>
<div><br class="">
</div>
<div class="">Olaf</div>
<div class=""><br class="">
</div>
<div class="">RFC 6781 3.2.2:</div>
<div class=""><br class="">
</div>
<div class="">
<pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always;"> However, the "operational habit" argument also applies to trust
anchor reconfiguration at the clients' validators. If a short key
effectivity period is used and the trust anchor configuration has to
be revisited on a regular basis, the odds that the configuration
tends to be forgotten are smaller. In fact, the costs for those
users can be minimized by automating the rollover with <a href="http://tools.ietf.org/html/rfc5011" class="">RFC 5011</a>
[<a href="http://tools.ietf.org/html/rfc5011" title=""Automated Updates of DNS Security (DNSSEC) Trust Anchors"" class="">RFC5011</a>] and by rolling the key regularly (and advertising such) so</pre>
<pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always;"> that the operators of validating resolvers will put the appropriate
mechanism in place to deal with these stability costs: In other
words, budget for these costs instead of incurring them unexpectedly.
</pre>
</div>
<div class=""><br class="">
</div>
<br class="">
<div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""> </div>
<div class="">Olaf Kolkman</div>
<div class="">(on personal title)</div>
<div class=""><br class="">
</div>
</div>
<br class="Apple-interchange-newline">
<br class="Apple-interchange-newline">
</div>
<br class="">
</body>
</html>