Multi-Signer DNSSEC Models
draft-ietf-dnsop-multi-provider-dnssec-05

Just a bunch of nits here:

Section 3:
Nits:
* "... a certain amount of delay.  Or that downstream ..." -- s/. O/, o/
* "Details of how the DNSKEY RRset itself is validated differs." -- s/differs/differ/

Section 5:
Nits:
* "Authentiated denial of existence ..." -- s/Authentiated/Authenticated/

Section 5.2:
Nits:
* "... different authentiated denial methods ..." -- s/authentiated/authenticated/
* "Resolver software may be however designed ..." -- s/may be however/may, however, be/ (or equivalent)
* "... more optimally than permanent setup ..." -- perhaps "more optimally than a permanent setup"?
* "... for a matching authentiated denial ..." -- s/authentiated/authenticated/

Section 7:
Nits:
* " A Combined Signing Key (CSK), is one ..." -- s/,//
* "i.e." should be "i.e.,"
* "In this case, any or all the providers could employ ..." -- s/all/all of/
* "... of all the other providers" -- s/all/all of/

Section 9:
Nits:
* "... with each others zone signing ..." -- s/others/other's/, and again later in the same sentence

Thank you for responding to the SECDIR review by Daniel Migault (and thanks for doing the review Daniel!)  The proposed clarifications would be helpful.

** Per Section 6.1, “Provider A would generate a new ZSK and communicate their intent to perform a rollover …”, how is that communication done? Just as the Security Considerations already talks about API security, is there an analogous thing to say here in Section 12?

** Section 12.  As key generation is invoked as a step in a number of these procedures, provide a pointer good practices for this step would be helpful, say Section 3.4.4 of RFC6781.

** Editorial Nits:
-- A few places.  Typo. s/Authentiated/ Authenticated/g

-- Section 5.1.  Typo. s/prefered/preferred/

-- Section 5.2. Typo. s/Aggresive/Aggressive/

Thanks for this document; it's pretty clear and it's good to have these
procedures written down in a well-thought-out manner.

Section 3

   o  It may also be the case that a resolver is unable to provide an
      authenticated response because it gave up after a certain number
      of retries or a certain amount of delay.  Or that downstream
      clients of the resolver that originated the query timed out
      waiting for a response.

nit: sentence fragment.

Section 5

   Since authenticated denial responses are self-contained, NSEC and
   NSEC3 can be used by different providers to serve the same zone.
   Doing so however defeats the protection against zone enumeration
   provided by NSEC3.  A better configuration involves multiple

It might be worth a few more words about why this defeats the protection
against zone enumeration.

Section 6.1, 6.2

Should we say anything about when it's safe for a new ZSK to be used to
sign responses?

Section 8

nit: s/CDNS/CDS/

Also, this section feels a bit sparse compared to 6.1 and 6.2.

Section 9

   In model 2, once initially bootstrapped with each others zone signing
   keys via these API mechanisms, providers could, if desired,
   periodically query each others DNSKEY RRsets and automatically import
   or withdraw ZSKs in the keyset as key rollover events happen.

What kind of authentication would be needed for this
provider-to-provider API access?

Section 10

Shouldn't we have references for DoT and DoH?

Section 12

I think both import and export need to be strongly authenticated, though
the DNSSEC itself can provide for authentication of export in most
(all?) cases.  If (e.g.) the zone owner fetches bad data and then
strongly authenticates to shove that bad data into the other services,
you still end up with bad data in use.
(Also, integrity protection, though I expect this is implicit.)

This is the sort of operation that I'd want to have multi-factor
authentication for, too.

Section 14.1

RFCs 2136, 5731 don't currently seem to be cited in a manner that
requires a normative reference.

My lack of domain knowledge made this document hard for me to understand, but given that this document as aimed at folks deploying DNS servers I don't really see that as a problem.

One note is that the draft does use quite a few acronyms and has no terminology section.  I'm not suggesting adding a terminology section but perhaps in the introduction it would be worth adding a sentence to point readers to  RFC 8499/BCP 219?  This should probably also be listed as an informative dependency (assuming that the terms used are formally defined elsewhere).