[Ssr2-review] Key rollover

[Eric Osterweil]

Alain,

Thanks for your note.  I don’t think I am the author of all of the text you refer to, but I have answered anyway.  My comments are inline, below

> On Jan 18, 2020, at 4:40 PM, ALAIN AINA via Ssr2-review <ssr2-review at icann.org> wrote:
> 
> 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?

I agree with your comments on that text, which showed up while we were all talking about it last week.  I have added my own suggestions to the document.

> 
> ====
> 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. 

I don’t think [m]any of the recommendations are in the plan, so I think it is important.  Can you help clarify why those recommendations shouldn’t be in the plan, and why we shouldn’t ask to have them added?

> 
> 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…..” 

Added some (different) suggested text, thanks.

Eric

> 
> ======
> 
> 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-01nov19-en.pdf
> 
> —Alain
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Ssr2-review mailing list
> Ssr2-review at icann.org
> https://mm.icann.org/mailman/listinfo/ssr2-review
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.