<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 11 January 2018 at 14:04, Ólafur Guðmundsson via ksk-rollover <span dir="ltr"><<a href="mailto:ksk-rollover@icann.org" target="_blank">ksk-rollover@icann.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail-h5"><br></div></div><div>Having said this I'm going to argue that we should proceed with roll by picking a day and </div><div>generating a PR outreach to try to minimize outages. </div><div><br></div></div></div></div></blockquote><div><br></div><div>I'm beginning to agree more and more with this position. </div><div><br></div><div>At the time the delay was announced, the only signal we had was the 8% of RFC8145 resolvers were not configured with the new key.  As far as I know, we still have all the same unanswered questions about that population that we had then:</div><div>1) What's the cause for software to be updated but configurations not to be?</div><div>1a) Are these "test" or "lab" instances?  Or are they being deliberately manually maintained for some reason?</div><div><br></div><div>And since we clearly can't assume a correlation between software and configuration maintenance, the 8% of the limited RFC8145-enabled population can't tell us anything about the non-8145 population.  So we didn't (and still don't) have any idea what the preparedness rate is for the internet as a whole.</div><div><br></div><div>The only potentially useful information that RFC8145 has given us (so far) about the Internet at large is an approximate rate at which new features get deployed into the resolver population.  While I've been surprised by the number of 8145-reporting resolvers out there, the growth rate doesn't seem to be high enough to give us a reason to be optimistic about any new data collection ideas that rely on resolver software changes. </div><div><br></div><div>Unless there are new ideas for how to collect data on those populations, that don't involve software updates, then we have no expectation to have new and useful information to base a go/no-go decision on.  And without new data, any suggestions we make here about criteria for determining when to restart the roll process are moot.</div><div><br></div><div>On that basis, I think we have to take the position that breakage is inevitable, minimize it as best we can with a PR campaign, and deal with the remaining brokenness when it comes.  Without hope of new data, every week we delay just makes the scope of the problem worse.</div><div><br></div><div><br></div></div></div></div>