Wes and I talked a bit about this at Berlin. The hold down time is the absolute minimum amount of time the publisher has to wait before he can believe the first resolver has installed the new trust anchor into the trust anchor set, NOT the maximum time it takes for all possible resolvers to accept the key. This much should have been obvious based on DNSs built in incoherence with respect to global state. <div><br></div><div>5011 is written to describe resolver behavior in the face of publisher activity. The actual uptake rate for resolvers may actually be slower than the holddown time for lots of reasons, and a publisher needs to consider all factors before deciding what the deployment completion point is. My own recommendation is to use 2x the holddown time as a minimum for the publisher to declare success. That probably gives you a 99.9% confidence interval that live 5011-capable resolvers have installed the new anchor. <br><div><br></div><div>At the time 5011 was published, there was some discussion on publishing an operational guidance document, but that fell by the wayside. </div><div><br></div><div>Mike</div><div><br></div><div><br><br><br>On Monday, August 1, 2016, Warren Kumari <<a href="mailto:warren@kumari.net">warren@kumari.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wanted to quickly draw people's attention to a draft which Wes<br>
Hardaker and I recently wrote:<br>
Security Considerations for RFC5011 Publishers<br>
draft-hardaker-rfc5011-security-considerations-00<br>
<br>
This discusses the minimum time which a TA publisher must wait before<br>
they can assume that (online) resolvers have the new key.<br>
Many people (e.g in the above) assume that it is 30 days, but it<br>
actually significantly longer - 30 days + 3/2 sig + 2*TTL<br>
<br>
Assuming everyone has the new key before this time is dangerous...<br>
<br>
W<br>
<br>
<br>
On Mon, Jul 25, 2016 at 6:50 AM, Stephane Bortzmeyer <<a href="javascript:;" onclick="_e(event, 'cvml', 'bortzmeyer@nic.fr')">bortzmeyer@nic.fr</a>> wrote:<br>
> The Yeti test bed is currently trying a second KSK rollover<br>
> <<a href="https://github.com/shane-kerr/Yeti-Project/blob/experiment-kroll/doc/Experiment-KROLL.md" target="_blank">https://github.com/shane-kerr/Yeti-Project/blob/experiment-kroll/doc/Experiment-KROLL.md</a>><br>
> and there was a funny incident. A resolver admin, misinterpreting the<br>
> instructions, updated manually his config with the new key, despite<br>
> the fact it was still in AddPend state and not used for signing. Since<br>
> people have a tendency to make mistakes, I suggest to pay extreme<br>
> attention to the communication and documentation, when explaining<br>
> sysadmins what to do.<br>
><br>
> _______________________________________________<br>
> ksk-rollover mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'ksk-rollover@icann.org')">ksk-rollover@icann.org</a><br>
> <a href="https://mm.icann.org/mailman/listinfo/ksk-rollover" target="_blank">https://mm.icann.org/mailman/listinfo/ksk-rollover</a><br>
<br>
<br>
<br>
--<br>
I don't think the execution is relevant when it was obviously a bad<br>
idea in the first place.<br>
This is like putting rabid weasels in your pants, and later expressing<br>
regret at having chosen those particular rabid weasels and that pair<br>
of pants.<br>
---maf<br>
_______________________________________________<br>
ksk-rollover mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'ksk-rollover@icann.org')">ksk-rollover@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/ksk-rollover" target="_blank">https://mm.icann.org/mailman/listinfo/ksk-rollover</a><br>
</blockquote></div></div>