[Comments-proposal-future-rz-ksk-rollovers-01nov19] Comments to "Future Root Zone KSK Rollovers Plan"

[Satsuki Hori]

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