Early Review of draft-ietf-dnsop-dnssec-automation-02
review-ietf-dnsop-dnssec-automation-02-dnsdir-early-tale-2024-03-18-00

Early review of draft-ietf-dnsop-dnssec-automation.

The process itself seems to be reasonably described.  I don't have any
suggestions as to the basic steps proposed.

Questions:

Section 2 is titled "Use Cases" but 2.1 isn't a use case and shouldn't
be its own section, especially since section 2[.0] has no text.  The
short Section 2.2 is the (only?) use case, suggesting that there need
be no separate sections at all and that it should just be titled "Use
Case".  If there are other use cases, they should be described.

Section 3 says "a zone operator should carefully choose", but
multi-signer has multiple operators.  Do you mean to say the zone
owner, or "any one of the zone operators".  Maybe it is easier just to
say "Automation of the necessary steps can be categorized into two
main models, centralized and decentralized, and each have pros and
cons," while kind of glossing over just who is making the decision as
the decider is not especially relevant as to standardization.

This does lead to further questions in 3.1 though as to just who "the
zone operator" is, with the term again being used as singular and not
having been defined in the Notation section.  In common parlance
within the industry, I'd not necessarily call the operator of the
"centralized controller" the "zone operator".  Maybe "zone
maintainer", suitably definied earlier, is better?  But also the
Notation section just called it an "entity" who runs the controller.

In Section 4.5 step 9, ZSK/CSK?

In Security Considerations, I found this to be a little awkward and
not usefully guiding: "Some providers or software installation[s]
allow [who?] to make more specific configuration on the allowed
changes.  All extra steps to allows as little access to change zone
data as possible should be taken."  I'm not quite sure what is really
being said here. That some are providers/software are too flexible in
what they permit and should be locked down? Perhaps an example would
help.

More minor nits:

Multi-Signer is inconsistently capitalized throughout.  It ought not
to be capitalized.  It isn't in RFC 8901 that defines it.

Section 1.1, "Out-of-Scope", seems superfluous to me.  At first I was
going to suggest that the parenthetical which suggested ways of
synchronizing between providers be stricken if it's out of scope to be
discussing it, but on further consideration it feels like the whole
section should be stricken.

The formatting of the 1.2 Notation section and then the following 1.3
section is inconsistent with typical draft formatting.  These would
typically be combined into a section 2, Terminology.  See RFC 9432 for
an example.

3.1, "will run controller" -> "will run a controller"

"Signer" is inconsistently capitalized.  I'd go with consistently
lowercase except, of course, at the start of sentences.

4.1 step 3 says "Signer or controller" then step 4 says just "Signer
controller" and I'm not quite sure how to parse that out.  If subject
of each sentence is meant to be the same thing, I'm guessing it is
"Signer controller" without the "or", in which case it should also
probably not have the "Signer" either since prior usage just referred
to role as "controller".

4.1 step 5, what's a lowercase "must"?  It's not clear if the
following "Otherwise" is a statement of what to do if there is no
parent CDS/CDNSKEY/CSYNC scanner or instead is a rationale for why the
scanner requirement is "must" since this is a draft about automation.
If the former, then "must" should be "SHOULD", and if the latter then
"must" should be "MUST".  Also the "otherwise" is a dependent phrase
and should be joined with a comma.

I'd move 4.2 Definitions ahead of 4.1 Prerequisites. Personally I also
wouldn't give it a subsection number, and would use formatting typical
for definition/terminology in RFCs.

Out in the wild there's a bit of inconsistency about whether it is
"DNSSEC-signed" or "DNSSEC signed", but personally I believe it should
be hyphenated as a compound adjective.

The algoritm steps refer to DS-Wait-Time, NS-Wait-Time, and
DNSKEY-Wait-Time, but these were previously defined as DS Waiting
Time, NS Waiting Time, and DNSKEY Waiting Time.

Section 5, the second paragraph as a "therefor" feels like it should
be joined into the first paragraph.

For "the following scenarios", add a colon.

"well supported" -> "well-supported" compound adjective.

Section 7, IANA Considerations, needs to explicitly say that no IANA
action is needed.

Section 8, Implementation Status, should follow Section 9, Security
Considerations.

In section 9, "at the right time and date", "and date" is redundant.

"Any failure could resolve in" -> "Any failure could result in"

"Independently of the chosen model" -> "Independent of the chosen model"

"If used correctly the multi-signer algorithm will strengthen the DNS
security by avoiding "going insecure" at any stage of the domain life
cycle." -> "If used correctly, the multi-signer algorithm will
strengthen DNS security by avoiding ever going insecure."