[DNSOP] Re: draft-ietf-dnsop-cds-consistency-09 ietf last call Dnsdir review

[Peter Thomassen <[e-mail]>]

Hi David,

Thanks a lot for your review!

On 10/23/25 22:50, David Blacka via Datatracker wrote:
> On August 30, 2023, I did an early review of
> draft-ietf-dnsop-cds-consistency-03.
> 
> My primary concerns in that review were that the draft should define the
> "multi-provider" (or whatever) term, or don't mention it at all; the interaction
> with CSYNC records wasn't fully clear; and, handling non-responsive nameservers
> wasn't clear.
> 
> These have all been addressed.  "Multi-provider setup" is defined (along with
> "multi-signer setup"); use with CSYNC has been made clear; and there is some
> advice on dealing with non-responsive nameservers.

That's good to hear!

> I have a few minor nits and editorial advice.
> 
> In the Abstract:
> 
>      This document specifies that when performing such queries,
>      parent-side entities has to ensure that updates triggered via
>      CDS/CDNSKEY and CSYNC records are consistent across the child's
>      authoritative nameservers, before taking any action based on
>      these records
> 
> s/has/have -- The subject of that sentence is "entities", which is plural, so we
> need "have" instead of "has" here.

Thank you. As this may be the only change (pending the below issue), I prefer to take this up with the RFC Editor instead of going through resubmission and triggering a bunch of notification emails to various groups.

> In Section 3:
> 
>      To accommodate transient inconsistencies (e.g., replication
>      delays), implementations MAY be configurable to undertake a
>      retry of the full process, repeating all queries (suggested
>      default: enabled). A schedule with exponential back-off is
>      RECOMMENDED.
> 
> I wonder if we should talk about making a configuration or just talk about what
> we thing the implementations should actually do?
> 
> Perhaps:
> 
>      Implementations SHOULD/MAY retry the full process when
>      encountering inconsistencies to account for transient
>      inconsistencies (e.g., replication delays.)

Your proposed text is almost identical to text we had previously, which was then changed upon a suggestion by Med (see [1] and the subsequent thread unfolding).

I'll be happy to change the text back if this is where consensus falls. Perhaps Med (or others) can comment; I've cc'ed him.

Best,
Peter


[1]: https://mailarchive.ietf.org/arch/msg/dnsop/MdbnX7ic59kDf5-eqqJ5uqEI-bE/ and search for "whether this is retried or not should be controlled using a knob"