Comments to "Future Root Zone KSK Rollovers Plan" 31 Jan 2020, Satsuki HORI and Yoshiro YONEYA (JPRS) Preamble ======== Basically, we support this plan. Our comments below are intended to point out places to be more understandalbe, and give suggestions to make the concept of the plan more clear. Comment 1 ========= We understood that the targeted readers of this plan are: (a) Internet Users (mainly full service resolvers' operators) (b) DNS product (software, appliance, etc.) developers (c) Root zone management partners and TCRs Under this understanding, we suggest that Section 2.1 should be broken down from the perspective of these three (a, b and c) readers. That is, what kind of impacts/influences will each target reader suffer from each phase, and what kind of preparation should be taken by them. For example, add information like below: (Please note that this example is not exhaustive and comprehensive.) Phase Target Impacts/Preparations A a No impacts b No impacts c New KSK generation (Key Ceremony) B a No impacts b Append new TA to TA file, update product package c Publish new TA, KSK delivery to another KMF (Key Ceremony) C a No impacts b (the same with Phase B) c Prepare new DNSKEY including new KSK (Key Ceremony) D a Monitor changes regarding to RFC 8145,8509 Update TA file and/or DNS software package if not using RFC 5011 b (the same with Phase B) c Publish new DNSKEY (Zone update) E a Confirm successful RFC 5011 behaviour b No impacts c Change DS to new KSK's (Zone update) F a Monitor changes regarding to RFC 8145,8509 b No impacts c Publish old KSK for revocation (Zone update) G a Update TA and/or DNS software if not using RFC 5011 b Remove old KSK from TA file, update product package c Delete old KSK from KMF (Key Ceremony) H a No impact b No impact c Delete old KSK from KMF (Key Ceremony) Timeline chart in Section 2.1 should be broken down as well from the perspective of three readers. Especially, for the reader (a), please remark that the important date is 11th day of the first month of Phase E and F (DS/DNSKEY publish date). Comment 2 ========= Given that new KSK has a role of standby key, start timing of new KSK's Phase D should be just after old KSK's Phase F. By doing so, non-existence period of standby key can be minimised without increasing DNSKEY size. More precisely, (1) non-existence period of standby key could be limited during old KSK's Phase F, and (2) KSK in published DNSKEY could be always 2 (DNSKEY size could be stable). Comment 3 ========= The meaning of dash line just after the start of Phase D and F in timeline chart at Section 2.1 is unclear. If it has meaning, it should be described clearly, otherwise, the dash line should be removed. Best regards, Satsuki and Yoshiro