Early Review of draft-ietf-dnsop-cds-consistency-03
review-ietf-dnsop-cds-consistency-03-dnsdir-early-blacka-2023-08-30-00

This draft is well-written and addresses a real operational concern: the
breaking of delegations when processing CDS/CDNSKEY and CSYNC records from an
out-of-step nameserver.

From a specification-purity point of view, the concept of multiple providers is
actually not needed or relevant to this draft.  Nameservers could be out of
sync for a variety of reasons.  This draft could be written without a single
mention of multi-provider (multi-homed?) or multi-signer situations and be
shorter and perhaps clearer.  Although, it might be important to point out that
there are more reasons than just being out-of-sync from a single primary source.

On the other hand, knowing that multiple provider setups exist is a strong
motivator for this specification.  Without considering multiple provider
setups, we are prone to imagining that all setups are synced from a single
source, and all deviation is temporal and temporary.

This draft uses the term "multi-homing" in a number of places.  I'm not aware
of that being a generally understood term in the context of DNS.  The draft
seems to use "multi-homing" and "multi-provider" interchangeably. 
"Multi-provider" is more understandable to me from its plain meaning, but it is
also not defined.  RFC 8901 uses the term "Multi Signer", and does not define
any other terms for this class of operational situations.  Appendix A.3 of this
draft almost defines the term as "Permanent Multi-Signer", although RFC 8901
generally refers to Multi Signer as permanent.

If the draft is not recast to just not directly mention
multi-homing/multi-provider/multi-signing setups, it should define the term
near the start of the draft.  I would prefer using "multi-provider" because I
believe it is both clearer and less encumbered with other meanings in nearby
subjects (like networking), and perhaps covers more situations than
"multi-signer".

My last major concern is with section 2.2, CSYNC.  RFC 7477 has many rules that
a parental agent must consider before accepting a CSYNC update.  It is unclear
how those rules interact with the rules specified in section 2.2.  I think what
is meant is this:

    Each parent-side nameserver is queried for the CSYNC RRset and the synced
    (NS, A, AAAA) RRsets, and that unless all of the CSYNC type map bits and
    sync data match, syncing must be aborted.

I think some discussion of how this interacts with the existing rules is
warranted.  For example, the type bitmap indicates "A", but the nameservers are
not at/below the delegation, so are ignored.  Does it matter to the algorithm
if the child nameservers have different data for the glue records?

I have a few minor language tweaks that I noted while reading this draft.

In the abstract:

    Parent-side entities (e.g. Registries, Registrars) typically discover these
    records by querying them from the child, and then use them to update the
    delegation's DS RRset accordingly.

Since we are already talking about both CDS/CDNSKEY and CSYNC, we should
probably be a little more inclusive here:

  Parent-side entities (e.g. Registries, Registrars) typically discover these
  records by querying them from the child, and then use them to update the
  delegation's DS and/or NS RRset accordingly.

Although that also doesn't quite capture everything, either.

In section 2, "Processing Requirements"

    When a response cannot be obtained from a given nameserver, the Parental
    Agent SHOULD attempt obtaining it at a later time

should be:

    When a response cannot be obtained from a given nameserver, the Parental
    Agent SHOULD attempt to obtain it at a later time

I will point that I noted some concern about the overall approach in the IETF
117 dnsops meeting.  I don't entirely recall the details of the concerns, but I
think it was about making CDS/et al. more brittle operationally.  This would be
true if this draft were not clear about how to handle non-responsive
nameservers.