Re: [ksk-rollover] Starting discussion on acceptable criteria for proceeding with the root KSK roll
Hi Geoff, At 04:19 PM 04-01-2018, Geoff Huston wrote:
Carlos, (I'm asking because you posted a "me too") what is the data set you are using to justify this call to be "over soon"? It seems to me that in the absence of new data, the only changed factor is your own appetite for risk. Without additional data, your tolerance for risk appears to increase over time (*). But is this altered personal perception of the risk sufficient motivation to proceed? Objectively, if the numbers in September 2017 gave sufficient grounds to pause, and the numbers haven't changed (**) then surely the grounds for pausing the operation as as strong now as they were in September (***).
There is the following in the KSK rollover plan: "The Design Team is unaware of what specific objectives would be achieved by delaying a KSK roll". The plan was put on hold because of the data from September 2017. At the moment it is unknown if/when there will be a KSK roll. Is not doing a KSK roll by 2020 [1] a viable option? Regards, S. Moonesamy 1. The date is based on a statement in the DPS.
Hi there, My half of cent to this discussion! I agree with the people that say that we should roll ASAP. IMO, I still think that the data that made ICANN stop the roll is very few and may not have the relevance that we are giving it. In my personal experience I was evangelizing the local community and the first question that we got back as the roll was stoped was "Ok, and when will it happen, now?". Not having a answer to give back was very frustaiting and I got the feeling from the community that they trust and interest on the subject. Loosing this momentum its a problem for me and will make people not wanting to know about the subject any more in the future. Getting back to the point in discussion: So we need to provide ICANN with a metric of what is accepteble for the roll to continue. IMO, this will always need to be eyeballs and no resolvers, so the efforts made by kskroll-sentinel will be the more effetive in this measure. But one question remains, will we have data in time for an effetive roll or will we need to wait until 2020? Best regards, Eduardo S Moonesamy escreveu às 10:03 de 05/01/2018:
Hi Geoff, At 04:19 PM 04-01-2018, Geoff Huston wrote:
Carlos, (I'm asking because you posted a "me too") what is the data set you are using to justify this call to be "over soon"? It seems to me that in the absence of new data, the only changed factor is your own appetite for risk. Without additional data, your tolerance for risk appears to increase over time (*). But is this altered personal perception of the risk sufficient motivation to proceed? Objectively, if the numbers in September 2017 gave sufficient grounds to pause, and the numbers haven't changed (**) then surely the grounds for pausing the operation as as strong now as they were in September (***).
There is the following in the KSK rollover plan: "The Design Team is unaware of what specific objectives would be achieved by delaying a KSK roll". The plan was put on hold because of the data from September 2017. At the moment it is unknown if/when there will be a KSK roll. Is not doing a KSK roll by 2020 [1] a viable option?
Regards, S. Moonesamy
1. The date is based on a statement in the DPS. _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Fri, 5 Jan 2018, S Moonesamy wrote:
At 04:19 PM 04-01-2018, Geoff Huston wrote:
Carlos, (I'm asking because you posted a "me too") what is the data set you are using to justify this call to be "over soon"?? It seems to me that in the absence of new data, the only changed factor is your own appetite for risk. Without additional data, your tolerance for risk appears to increase over time (*). But is this altered personal perception of the risk sufficient motivation to proceed? Objectively, if the numbers in September 2017 gave sufficient grounds to pause, and the numbers haven't changed (**) then surely the grounds for pausing the operation as as strong now as they were in September (***).
There is the following in the KSK rollover plan: "The Design Team is unaware of what specific objectives would be achieved by delaying a KSK roll". The plan was put on hold because of the data from September 2017. At the moment it is unknown if/when there will be a KSK roll. Is not doing a KSK roll by 2020 [1] a viable option?
As a Design Team member, let me say that the Design Team no longer really exists, and that we did not call for the delay. At the time, there were no statistics to base and decision on. We have some now from Sep 2017. It would be nice to get more. I understand ICANN was also trying to find out more and hired people to do so. What happened to that effort? Do we have new data? Do we have new sources of bad behaviour (eg software versions, OS versions, other issues?). Have we ruled out any software design/deployment issues? If we are waiting on more data, lets finish with the data. If we are not gathering more data, then there isn't any point in waiting. As for the voices of dnssec critics, most of that is so biased that there isn't much point of considering it. Or as Taylor Swift wisely said, Haters gonna hate hate hate hate. Paul
On Jan 5, 2018, at 1:25 PM, Paul Wouters <paul@nohats.ca> wrote:
At the time, there were no statistics to base and decision on. We have some now from Sep 2017. It would be nice to get more. I understand ICANN was also trying to find out more and hired people to do so. What happened to that effort? Do we have new data? Do we have new sources of bad behaviour (eg software versions, OS versions, other issues?). Have we ruled out any software design/deployment issues?
From https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project (18 December 2017):
Since then, we have attempted to contact the operators of 500 addresses that had reported a resolver configuration with only KSK-2010 instead of the correct configuration of both KSK-2010 and the new KSK, KSK-2017. Ideally, that investigation would have revealed a set of clear causes for the improper configuration, allowing further communication and actions to be targeted at addressing those specific issues. But in the end, the analysis was not as conclusive as we would have hoped.
In our initial attempt, we received a response from operators of approximately 20% of the 500 addresses. Of those addresses whose operators we could contact, 60% came from address ranges known to host devices with dynamic addresses, such as routers of home broadband users and ephemeral virtual machines, making these resolvers extremely difficult (if not impossible) to track down. About 25% of the addresses corresponded to a resolver forwarding on behalf of another resolver that was reporting only KSK-2010. Since the address of the device reporting the incorrect configuration was not the actual source resolver, it is extremely difficult (if not impossible) to identify the true source address of the resolver that was reporting only KSK-2010.
Not surprisingly, tracking down operators of individual IP addresses is hard and, of those we could contact, there is no smoking gun. Your questions are reasonable and I'm realizing that we can and should publish the report of the contractor we engaged to try to reach those 500 addresses, which will show the unfortunate lack of smoke. Now that we've gotten about as far as we can on our own with that line of investigation, we're starting to enlist the help of the ISPCP and RIRs, whom we've previously reached out to and who have expressed a willingness to help. We'll be sending them the specific IPs to see whom they can track down and what they can find. I continue to believe what we reported back in September as the reason for the rollover postponement: we need to understand whatever signal there is in the RFC8145 trust anchor reports better to know how to proceed. But I'm open to suggestions: that's why we want to have this discussion.
If we are waiting on more data, lets finish with the data. If we are not gathering more data, then there isn't any point in waiting.
We're still gathering data. ICANN has RFC8145 data from eight root server letters now (with more hoped for). We're at this moment preparing an update of what we've seen since September and will have that within a couple weeks, hopefully sooner. Matt
Hi Paul, At 10:25 AM 05-01-2018, Paul Wouters wrote:
As a Design Team member, let me say that the Design Team no longer really exists, and that we did not call for the delay.
At the time, there were no statistics to base and decision on. We have some now from Sep 2017. It would be nice to get more. I understand ICANN
I read the 2015 report again. Under "Risk Analysis", the impact of a "Lack of deterministic criteria to make go/no-go decision" was rated as "Low". The topic of this thread is about an acceptable criteria to go ahead. There is a 2016 report; under "Risk Analysis", the impact of "Indefinitely postponing a key rollover increases the impact if it becomes urgent." is rated as "High". Regards, S. Moonesamy
Hi, On January 5, 2018 at 2:06:10 AM, S Moonesamy (sm+icann@elandsys.com<mailto:sm+icann@elandsys.com>) wrote: The plan was put on hold because of the data from September 2017. At the moment it is unknown if/when there will be a KSK roll. Is not doing a KSK roll by 2020 [1] a viable option? Speaking personally, I’m hoping we can do the rollover long before 2020. The key is for the community to provide some sort of guidance to the ICANN Org about how to move forward. So far, my impression is that to date, most of the input from this mailing list has been “do it now”, implying we do NOT need to assess "the impact on users” (as mentioned in https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project). This means that the plan that will be published on 31 January for public comment will say the input we have received suggests the majority of contributors do not believe we need to take potential negative impact of the KSK rollover into account. 1. The date is based on a statement in the DPS. Sorry, which statement? Thanks, -drc
Hi David, At 02:12 PM 05-01-2018, David Conrad wrote:
Speaking personally, I'm hoping we can do the rollover long before 2020. The key is for
I'll reply to the question at the end of your message; this is the statement: "Each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation."
the community to provide some sort of guidance to the ICANN Org about how to move forward. So far, my impression is that to date, most of the input from this mailing list has been "do it now", implying we do NOT need to assess "the impact on users" (as mentioned in https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project). This means that the plan that will be published on 31 January for public comment will say the input we have received suggests the majority of contributors do not believe we need to take potential negative impact of the KSK rollover into account.
The discussion on this mailing list has been about trust and uncertainty. Is the potential negative impact mentioned above about the "4% of the approximately 12,000 DNSSEC-validating resolvers"? If so, has there been any discussion about the data? Regards, S. Moonesamy
On January 5, 2018 at 3:28:36 PM, S Moonesamy (sm+icann@elandsys.com<mailto:sm+icann@elandsys.com>) wrote: "Each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation." Yes. But I’m still not seeing where 2020 comes in. All the above is saying is that the 2010 KSK was in a position to be rolled after 2015. The discussion on this mailing list has been about trust and uncertainty. What we’re looking for is some direction from the community on how to determine an "agreed understanding of when the rollover has affected operational stability beyond a reasonable boundary”. Is the potential negative impact mentioned above about the "4% of the approximately 12,000 DNSSEC-validating resolvers"? Sorry, where are you getting your numbers? If so, has there been any discussion about the data? To be clear, we’re now seeing about 8% of the RFC 8145-reporting resolvers (which is, of course, a subset of all validating resolvers) indicating they’re configured for only KSK-2010. The issue is that we have no good idea of figuring out how many end users that percentage is representing and what the implications of breaking resolution for those end users will be. Regards, -drc
Hi David, At 09:37 AM 07-01-2018, David Conrad wrote:
Yes. But I'm still not seeing where 2020 comes in. All the above is saying is that the 2010 KSK was in a position to be rolled after 2015.
The first KSK was introduced in 2010. That statement is about doing a KSK after five years. I multiplied the duration by two, hence the year 2020. There was a discussion about the rollover in 2013. The delays since them could be interpreted as meaning that the KSK roll is indefinitely postponed. At some point there may be discussions about whether all this is reliable.
Sorry, where are you getting your numbers?
The numbers are from https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project
To be clear, we're now seeing about 8% of the RFC 8145-reporting resolvers (which is, of course, a subset of all validating resolvers) indicating they're configured for only KSK-2010. The issue is that we have no good idea of figuring out how many end users that percentage is representing and what the implications of breaking resolution for those end users will be.
According to data published by APNIC, 10.82% of DNSSEC validation worldwide is from Google Public DNS. It should be possible to take that number out of the equation by talking with someone at Google. The (8%) number is not meaningful if I cannot explain it in an easily understandable manner. Would breaking resolution have an impact which is similar to the 2016 Dyn outage? Would it take down a significant part of the internet in a country? Regards, S. Moonesamy
According to data published by APNIC, 10.82% of DNSSEC validation worldwide is from Google Public DNS. It should be possible to take that number out of the equation by talking with someone at Google.
I have to interject that what you have reported here is NOT not a correct interpretation of the data published by APNIC. Geoff
Hi Geoff, At 04:16 PM 07-01-2018, Geoff Huston wrote:
I have to interject that what you have reported here is NOT not a correct interpretation of the data published by APNIC.
Thank you for the above. Is there an estimate of the usage of Google Public DNS as a percentage of DNSSEC validation worldwide? Regards, S. Moonesamy
On 8 Jan 2018, at 5:46 pm, S Moonesamy <sm+icann@elandsys.com> wrote:
Hi Geoff, At 04:16 PM 07-01-2018, Geoff Huston wrote:
I have to interject that what you have reported here is NOT not a correct interpretation of the data published by APNIC.
Thank you for the above. Is there an estimate of the usage of Google Public DNS as a percentage of DNSSEC validation worldwide?
Its not as simple as this - users typically are configured with a number of DNS resolvers (2 is most common) and when the first resolver does not answer or returns SERVFAIL then they try the second, and so on. What APNIC publishes at https://stats.labs.apnic.net/dnssec is 2 numbers: a) DNSSEC Validate - ALL the resolvers that are called by the user’s DNS perform DNSSEC validation, and the user will not resolve a DNS name when that name is signed, but the signature cannot be validated b) Uses Google’s Public DNS data service - the count of users that will call Google’s service to resolve a name, but may also call other resolvers if the response from the Google resolver is SERVFAIL I think you are after a number that is the number of users that use Google’s Public DNS service and no other resolver. We do not publish that number as we don’t calculate it from the raw data. Or perhaps you are after the number of users that exclusive use DNSSEC-validating resolvers, one of which is Google’s validation service. Again, we do not publish that number as we don’t calculate it from the raw data. regards, Geoff
Hi Geoff, At 11:22 PM 07-01-2018, Geoff Huston wrote:
Its not as simple as this - users typically are configured with a number of DNS resolvers (2 is most common) and when the first resolver does not answer or returns SERVFAIL then they try the second, and so on.
What APNIC publishes at https://stats.labs.apnic.net/dnssec is 2 numbers:
a) DNSSEC Validate - ALL the resolvers that are called by the user's DNS perform DNSSEC validation, and the user will not resolve a DNS name when that name is signed, but the signature cannot be validated
b) Uses Google's Public DNS data service - the count of users that will call Google's service to resolve a name, but may also call other resolvers if the response from the Google resolver is SERVFAIL
Thank you for explaining the above.
I think you are after a number that is the number of users that use Google's Public DNS service and no other resolver. We do not publish that number as we don't calculate it from the raw data.
Or perhaps you are after the number of users that exclusive use DNSSEC-validating resolvers, one of which is Google's validation service. Again, we do not publish that number as we don't calculate it from the raw data.
It was the second option (use DNSSEC-validing resolovers). Regards, S. Moonesamy
On 2018-01-07 at 12:19 -0800, S Moonesamy wrote:
Hi David, At 09:37 AM 07-01-2018, David Conrad wrote:
Yes. But I'm still not seeing where 2020 comes in. All the above is saying is that the 2010 KSK was in a position to be rolled after 2015.
The first KSK was introduced in 2010. That statement is about doing a KSK after five years. I multiplied the duration by two, hence the year 2020.
There was a discussion about the rollover in 2013. The delays since them could be interpreted as meaning that the KSK roll is indefinitely postponed. At some point there may be discussions about whether all this is reliable.
Sorry, where are you getting your numbers?
The numbers are from https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project
To be clear, we're now seeing about 8% of the RFC 8145-reporting resolvers (which is, of course, a subset of all validating resolvers) indicating they're configured for only KSK-2010. The issue is that we have no good idea of figuring out how many end users that percentage is representing and what the implications of breaking resolution for those end users will be.
According to data published by APNIC, 10.82% of DNSSEC validation worldwide is from Google Public DNS. It should be possible to take that number out of the equation by talking with someone at Google.
The (8%) number is not meaningful if I cannot explain it in an easily understandable manner. Would breaking resolution have an impact which is similar to the 2016 Dyn outage? Would it take down a significant part of the internet in a country?
Regards, S. Moonesamy
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Hi, On January 7, 2018 at 12:54:49 PM, S Moonesamy (sm+icann@elandsys.com<mailto:sm+icann@elandsys.com>) wrote: The first KSK was introduced in 2010. That statement is about doing a KSK after five years. I multiplied the duration by two, hence the year 2020. I don’t think the idea was that there would be a slot every 5 years and if we missed a slot, we’d have to wait until the next slot 5 years later (or, alternatively, that we’d have to accelerate the next roll to be less than 5 years if the roll took time). I would presume that without further direction by the community, the next roll will occur 5 years after we put KSK-2017 into operation. The question here is when will we be putting KSK-2017 into operation. There was a discussion about the rollover in 2013. The delays since them could be interpreted as meaning that the KSK roll is indefinitely postponed. At some point there may be discussions about whether all this is reliable. We were on track to roll the KSK on 11 Oct 2017. We postponed the roll as a result of new information days before we were intending to move forward. Suggesting that this means an indefinite postponement seems a bit of a reach to me. The (8%) number is not meaningful if I cannot explain it in an easily understandable manner. To be clear: the 8% number reflects the percentage of resolvers reporting according to RFC 8145 that have only KSK-2010 configured and which presumably would be unable to validate if we roll the KSK. The meaning of this is that we have concrete data that show a non-zero number of resolvers will fail, presumably impacting a non-zero number of end users. While this was suspected, prior to the RFC 8145 data, we did not have certainty. We still do not know how many end users will be impacted because we can’t tell how many end users are behind the resolvers that are reporting KSK-2010 only. Would breaking resolution have an impact which is similar to the 2016 Dyn outage? Would it take down a significant part of the internet in a country? We do not know. Regards, -drc
On 5.1.2018 23:12, David Conrad wrote:
On January 5, 2018 at 2:06:10 AM, S Moonesamy (sm+icann@elandsys.com <mailto:sm+icann@elandsys.com>) wrote:
The plan was put on hold because of the data from September 2017. At the moment it is unknown if/when there will be a KSK roll. Is not doing a KSK roll by 2020 [1] a viable option?
Speaking personally, I’m hoping we can do the rollover long before 2020. The key is for the community to provide some sort of guidance to the ICANN Org about how to move forward. So far, my impression is that to date, most of the input from this mailing list has been “do it now”, implying we do NOT need to assess "the impact on users” (as mentioned in https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project). This means that the plan that will be published on 31 January for public comment will say the input we have received suggests the majority of contributors do not believe we need to take potential negative impact of the KSK rollover into account.
I think this is misunderstanding. I haven't seen anyone saying that "we [do not] need to take potential negative impact of the KSK rollover into account", rather than "people will fix it if it really breaks". Let me state my interpretation of the discussion (in the following text, "contributors" reads "me"): Contributors believe that there is no way to reliably measure readiness for the rollover, and that tools for such measurement will not be available in upcoming years. --- While not having reliable data, contributors believe that KSK rollover process already got sufficient publicity and that breakage will be dealt with swiftly, similarly to other security issues or DDoS attacks. For these reasons risk of postponing KSK rollover indefinitely is deemed to be higher than risk of breakage which will be fixed using usual methods. --- I hope it helps to explain how others might read this discussion. -- Petr Špaček @ CZ.NIC
And we should work with all the major search engine to make the DNSSEC/DNS failure related searches are more relevant during the rollover, on terms like SERVFAIL, DNSSEC, DNS resolution failure, etc.... and links to resolve. They won't be searching for KSK rollover and it should be mobile friendly. The google top box (don't know what's it called) should say on DNS/DNSSEC search on the day we roll the key "We just rolled the KEY, if you're experiencing DNS issues, please ..." Jack
-----Original Message----- From: ksk-rollover [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Petr Špacek Sent: January 10, 2018 8:34 AM To: ksk-rollover@icann.org Subject: Re: [ksk-rollover] Starting discussion on acceptable criteria for proceeding with the root KSK roll
On 5.1.2018 23:12, David Conrad wrote:
On January 5, 2018 at 2:06:10 AM, S Moonesamy (sm+icann@elandsys.com <mailto:sm+icann@elandsys.com>) wrote:
The plan was put on hold because of the data from September 2017. At the moment it is unknown if/when there will be a KSK roll. Is not doing a KSK roll by 2020 [1] a viable option?
Speaking personally, I’m hoping we can do the rollover long before 2020. The key is for the community to provide some sort of guidance to the ICANN Org about how to move forward. So far, my impression is that to date, most of the input from this mailing list has been “do it now”, implying we do NOT need to assess "the impact on users” (as mentioned in https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project). This means that the plan that will be published on 31 January for public comment will say the input we have received suggests the majority of contributors do not believe we need to take potential negative impact of the KSK rollover into account.
I think this is misunderstanding. I haven't seen anyone saying that "we [do not] need to take potential negative impact of the KSK rollover into account", rather than "people will fix it if it really breaks".
Let me state my interpretation of the discussion (in the following text, "contributors" reads "me"):
Contributors believe that there is no way to reliably measure readiness for the rollover, and that tools for such measurement will not be available in upcoming years.
--- While not having reliable data, contributors believe that KSK rollover process already got sufficient publicity and that breakage will be dealt with swiftly, similarly to other security issues or DDoS attacks. For these reasons risk of postponing KSK rollover indefinitely is deemed to be higher than risk of breakage which will be fixed using usual methods. ---
I hope it helps to explain how others might read this discussion.
-- Petr Špaček @ CZ.NIC _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Wed, Jan 10, 2018 at 5:33 AM, Petr Špaček <petr.spacek@nic.cz> wrote:
On 5.1.2018 23:12, David Conrad wrote:
On January 5, 2018 at 2:06:10 AM, S Moonesamy (sm+icann@elandsys.com <mailto:sm+icann@elandsys.com>) wrote:
The plan was put on hold because of the data from September 2017. At the moment it is unknown if/when there will be a KSK roll. Is not doing a KSK roll by 2020 [1] a viable option?
Speaking personally, I’m hoping we can do the rollover long before 2020. The key is for the community to provide some sort of guidance to the ICANN Org about how to move forward. So far, my impression is that to date, most of the input from this mailing list has been “do it now”, implying we do NOT need to assess "the impact on users” (as mentioned in https://www.icann.org/news/blog/update-on-the-root-ksk- rollover-project). This means that the plan that will be published on 31 January for public comment will say the input we have received suggests the majority of contributors do not believe we need to take potential negative impact of the KSK rollover into account.
I think this is misunderstanding. I haven't seen anyone saying that "we [do not] need to take potential negative impact of the KSK rollover into account", rather than "people will fix it if it really breaks".
Let me state my interpretation of the discussion (in the following text, "contributors" reads "me"):
Contributors believe that there is no way to reliably measure readiness for the rollover, and that tools for such measurement will not be available in upcoming years.
--- While not having reliable data, contributors believe that KSK rollover process already got sufficient publicity and that breakage will be dealt with swiftly, similarly to other security issues or DDoS attacks. For these reasons risk of postponing KSK rollover indefinitely is deemed to be higher than risk of breakage which will be fixed using usual methods. ---
I hope it helps to explain how others might read this discussion.
I think there will always be breakage, in the old pre-RFC5011 and KSK design discussions there was one case identified as non-solvable --- old OS/Box comes alive i.e. I think we now have a second class of failures that was not "anticipated" -- non-persistence i.e. resolver can not store state in a way that will be used if resolver is restarted. -- operators hard code keys i.e. disable RFC5011 (trusted-keys vs managed-keys) RFC5011 assumes that timings and state of keys can be stored and will survive reboot/restart, this seems to be violated by some operators by design (i.e. configuration information is non-writeable by the Resolver process) and in some cases a mixture of the old OS and use of modern technologies like containers. 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. Olafur
Ólafur Guðmundsson via ksk-rollover <ksk-rollover@icann.org> wrote:
I think there will always be breakage, in the old pre-RFC5011 and KSK design discussions there was one case identified as non-solvable --- old OS/Box comes alive i.e. I think we now have a second class of failures that was not "anticipated" -- non-persistence i.e. resolver can not store state in a way that will be used if resolver is restarted. -- operators hard code keys i.e. disable RFC5011 (trusted-keys vs managed-keys)
I have a suggestion that could fix the first two, and also fix the secure time bootstrap problem - https://tools.ietf.org/html/draft-fanf-dnsop-trust-anchor-witnesses I should maybe do a simplified revision, but I'm not sure there's enough interest to make it worth the effort. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Shannon, Rockall: South 7 to severe gale 9, occasionally storm 10 at first in Rockall, becoming cyclonic 6 to gale 8. Very rough or high, occasionally very high at first in Rockall. Rain or showers. Good, occasionally poor.
On 11 January 2018 at 14:04, Ólafur Guðmundsson via ksk-rollover < ksk-rollover@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.
participants (12)
-
David Conrad -
Eduardo Duarte -
Geoff Huston -
Jacques Latour -
Matt Larson -
Matthew Pounsett -
Paul Wouters -
Petr Špaček -
S Moonesamy -
Tony Finch -
Ángel González -
Ólafur Guðmundsson