I would like to voice my support of the ICANN plan to restart the KSK rollover process. I was a member of the KSK Rollover Design team, and I am of the view that the plan as described in the Design Team was carefully appraised by ICANN staff, and the proposed plan to roll the key reflected the major objectives of the Design Team report and made some changes that further enhanced the resiliency and robustness of hte overall process. The decision to suspend the Planned KSK roll in 2017 was a responsible action in the light of unanticipated data from the reporting mechanisms from resolvers that apparently have implemented RFC8145. However, it is clear following further examination of the implicit signal from the RFC8145 mechanism that most of this signal contains mis-attribution of resolvers as being DNSSEC-validating resolvers and mis-attribution of resolvers through the various actions of query handling between the reporting resolver and the data collection points at the root. In other words, it is becoming apparent that the signal within the RFC8145 mechanisms is a largely flawed signal. There is still time between now and October 2018 to further study the RFC8145 data to confirm that much of this signal is flawed. There is still ample time to experiment with the proposed sentinel mechanism, but further delay at this point in time would, in my view, serve more to erode confidence in DNSSEC than it would build any further confidence in this proposed KSK roll process. Every crypto system needs an ability to change its key at some point. A regularly scheduled roll the key provides operational experience in this potentially rather esoteric activity, and one of the benefits, as I perceive it, is that we can gain experience with this event and use that experience to further enhance the process. It is an abstract exercise to wait for a ‘perfect’ key roll process, and I am of the view that experience will refine and enhance our thinking that an abstract exercise never can. Yes, there is a need for a clearer signal about the preparedness of the Internet’s DNSSEC-validaitng resolvers for the KSK roll, and yes, we might consider a mechanism that is different from that detailed in RFC5011, and yes, we might want to look at systems that include standby keys, but my position is that the best way to design refinements to this process is to use experience from each iteration to make incremental improvements. So, I am strongly supportive of the ICANN plan to restart the KSK rollover process. kind regards, Geoff Huston Chief Scientist, APNIC