Hi Eric and al Do we have evidence to back the statement below ? ==== The review team found no evidence that the propagation delay between publication to each of the letters, and then to each of a letter’s instances, is well l understood. However, propagation delay was an SSR issue as recently as the 2018 KSK rollover, when some instances were observed not to update as fast as others. ==== We need evidence and should understand when did this happen during the key rollover process and see the the relationship to the key rollover changes to the root zone. and also evaluate the impact it had. Was this due to the key rollover or just normal failure of the RSS to compliant to the service accuracy obligation in RSSAC001? ==== Recommendations: Formal Procedures for Key Rollovers This recommendation is broken down into two parts: implement existing recommendations (part 1), and additional recommendation (part2). Part 1: ICANN org should implement the recommendations from SAC063 and SAC073. ===== SSAC063 was considered by the design team who developed the KSK rollover Plan (https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf) and SSAC073 was just SSAC comment on the design team interim report. So i wonder if this part is really needed. As for the part2(below), as discussed during the last meeting i support referring to the document on “ Proposal for Future Root Zone KSK Rollovers “ which only addresses the issues of scheduling and implementing future KSK lifecycle and which is under public comment…(*) Something around this: "ICANN org should based on lessons learnt from 2017/2018 KSK rollover and beyond the effort to document "the scheduling and implementing a future KSK lifecycle", establish…..” ====== Part 2: ICANN org should establish a formal procedure, supported by a formal process modeling tool and language to specify the details of future key rollovers, including decision points, exception legs, the full control-flow, etc. Verification of the key rollover process should include posting the programmatic procedure (e.g., program, FSM) for public comment, and community feedback should be incorporated. The process should have empirically verifiable acceptance criteria at each stage, which should be fulfilled for the process to continue. This process should be reassessed at least as often as the rollover itself (i.e., the same periodicity) so that lessons learned can be used to adjust the process. ICANN org should create a group of stakeholders involving relevant personnel (from ICANN org or the community) to periodically run table-top exercises that follow the Root KSK rollover process. ==== Hope this helps (*) https://www.icann.org/en/system/files/files/proposal-future-rz-ksk-rollovers... —Alain