I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. Document
editors and WG chairs should treat these comments just like any other last
call comments.

The summary of the review is Ready with issues.

This Best Current Practice draft provides operational recommendations for
DNSSEC DS automation. Although it concerns DNSSEC automation, this is much
more of an operations BCP than a security BCP. It has an interesting
structure where Sections 4, 5, 6, and 7, which are the heart of the
document, each start with a number of operations questions that are
addressed by that section. A copy of the recommendations in those sections
is then gathered together and listed in Appendix A.

# Security

I believe there are security threats addressed by this document but it
seems to mostly focus on potential operational problems of "inconsistency"
and "unexpected and confusing" behavior. It might be useful to give some
examples of security problems that can be caused by ignoring these
recommendations or, if you are sure, to state that there are none (which I
doubt). How do these recommendations interact with the compromise of
various of the parties in the RRR model or with an on-path attacker?

# Minor

Section 4.2.2, last paragraph: Wouldn't there be some advantage to lowering
the TTL of the old DS RRset if you did so early enough before the DS update?

Section 4.2.3, last paragraph: I found this paragraph a little hard to
understand. What exactly does "Child DNS operators are held responsible for
publishing contradictory information" mean? Isn't it just that when a Child
DNS operator publishes contradictory information, the parent rejects it?
Also, doesn't a parent always have the power to publishes whatever DS or
other records it wants?

Section 5.1, point 3: Since there are specific recommendations in many
other cases, can something specific be said rather than "unnecessarily
frequently"? Like, for example, "a few times initially and once a day
thereafter".
On the other hand, Section 5.2, next to last paragraph says "no more than
twice in in a row" so maybe that is what is meant.

Section 5.2, after the numbered points: Consistent with the tone of other
parts of this document, I suggest "would be justified to attempt
communicating" -> "SHOULD communicate"

Section 7.1, point 1: "SHOULD" -> "MUST" ?

Section 7.2.3, 1st paragraph: I understand the basis for saying DS flapping
will only occur for a limited period of time. Is that the only basis for
saying it will only be a minor nuisance?

# Nits

Section 3, 2nd paragraph, first sentence. Not grammatical. Simplest change
would be to delete "as" but it is also too wordy. Suggest shortening to
"Recommendations in this document optimize interoperability and safety."

Section 4.1 point 1a and Appendix A.1, point 1a: "ambigious" -> "ambiguous"

Section 4.2.1, first line of last paragraph: perhaps the "may" should be
"MAY".

Section 6.2.2, last line: Some superfluous waffle wording here. "It
therefore appears that DS initialization and rollovers should ..." -> "DS
initialization and rollovers SHOULD ..."

Section 7.1, point 5: "has declared to be performing automated" -> "has
declared it performs automated"

Section 7.2.1, 1st paragraph, 2nd sentence: "the key used by for
authentication" -> "the key used for authentication"

Section 7.2.2, 2nd paragraph: suggest "It is therefore advised to not
follow this practice." -> "This practice is NOT RECOMMENDED."

Section 7.2.2, 4th paragraph: ends with a parenthetical where I believe the
parens are not needed. Check for other cases of this in the document.

Section 11: Spell out SSAC on first use.

# .sig

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com