As I stated in the meeting, I think this document is a great idea as an
addition to the RFCs about DNS(SEC). Kudos for writing it, and great
kudos for the diagrams and generally clear text.
Comments though:
*** Biggest one: I still believe that this document would be horribly
remiss without including the timing associated with RFC5011
processing. It's becoming more and more clear that zone operators
will be encouraged by their registrars to roll they're keys in 5011
compliant manners for automatic DS or DLV record updates to succeed
without requiring conversation. The extra timing constraints
introduced by RFC5011 aren't nearly as bad as the timing constraints
in the draft, and thus I think the increase in complexity will only
be a small fraction of what is already a complex situation.
I think it could be best handled by simply including a section near
the top that defines one term that is included in all the needed
equations below. That term would be 0 if you weren't doing RFC5011
processing or would be something like 30days + fudge, for example,
if you were. That wouldn't require making the text below more
complicated but would still show the important points in the process
where longer wait times are necessary.
I think this is critical and must be included. IMHO, of course.
But I'll do my best to adapt everyone else's HO as well.
* mention the appendix early in the doc as a handy reference. i.e. it's
highly useful to refer to when reading the doc itself
* 2.1: Dp => time delay fudge factor. I think the text, by the time you
get to the bottom, adequately describes the issues with needing to
wait a period of time that is highly variable because of operational
delays. I'd be tempted (since I think it's a confusing point to many)
to bring it up in it's own paragraph before the rest of the math
begins. Discuss the issues with propagation and possibly mention that
some code bases just use a standard doubling to ensure the timing is
safe (e.g. instead of waiting for just a TTL, wait for 2*TTL instead).
* 2.2.2: I think the wording could be a clearer here. That being said,
I haven't done the decency of suggesting an alternative paragraph or
two have I? (Sorry).
* 2.2.2: and others: I'd be tempted to use a different event enumeration
system. Group each set of events together so when you switch from one
scenario to another users can be sure you're not talking about the
same event. My initial thought was to use events of the form A.1,
A.2, ... and then switch to B.1 ... when switching to a different
timing discussion.
* 2.3.1, last word: "events" -> "external triggers" or "other triggers"
("events" already has way too much context above and thus a different
word would be better just to ensure it's not confused with the
previous text; pick the synonym of your choice)
* For acronyms/terms/abbreviations like "Nze" you have defined as "the
(n)umber of (e)mergency (Z)SKs". Most of the terms suffer from a
battle in user memorization because the ordering of the words differs
from the ordering of the letters. It took me half the document to
realize why I wasn't remember what each term was. There is a
consistence to the abbreviations that makes sense, so I think it'd be
better to simply reorder the words instead. For example "Nze" could
be "the number of ZSKs for use in emergencies". (this is actually a
harder one; most of the rest of them have an easier wording/ordering
swap than this example)
* I'd strongly recommend, when you get everything further along and
about finished, that you hand it to someone fresh to have them check
all the equations from scratch. Some of them are complex enough that
I wouldn't be surprised if an thinking error snuck in (not that I
don't have confidence in you! To err is human).
* 3.1, bullets 2 and 3: technically ZSKs can be pointed to by a DS and
can be used as trust anchors. It would probably be easiest if
you declared that aspect out of scope as it isn't the recommend usage
case.
* 3.1, paragraph ending in "and its publication in the zone.)":
I'd list Dr instead as the "time between publication of the key and
the DS publication" because the timing of when the parent was informed
is not as important as the time between the key publication and the DS
publication. When it was published to the parent is almost certainly
different from when the key first got published.
--
"In the bathtub of history the truth is harder to hold than the soap,
and much more difficult to find." -- Terry Pratchett
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
