[ksk-rollover] Starting discussion on acceptable criteria for proceeding with the root KSK roll

[Matthew Pounsett]

On 11 January 2018 at 14:04, Ólafur Guðmundsson via ksk-rollover <
ksk-rollover at icann.org> wrote:

>
> Having said this I'm going to argue that we should proceed with roll by
> picking a day and
> generating a PR outreach to try to minimize outages.
>
>
I'm beginning to agree more and more with this position.

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:
1) What's the cause for software to be updated but configurations not to be?
1a) Are these "test" or "lab" instances?  Or are they being deliberately
manually maintained for some reason?

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180114/86b8bd9b/attachment.html>