[DNSOP] Re: draft-ietf-dnsop-ds-automation-05 ietf last call Dnsdir review

[Peter Thomassen <[e-mail]>]

Hi Peter,

Thank you very much for your review!

On 5/6/26 20:43, Peter van Dijk via Datatracker wrote:
> This is a solid document. My concerns are tiny. Please find them below.
> 
> ```
> Parent (DNS operator):  The DNS operator responsible for a Parent
>        zone and, thus, involved with the maintenance of the delegation's
>        DNSSEC parameters (in particular, the acceptance of these
>        parameters and the publication of corresponding DS records).
> ```
> 
> The Parent (the party responsible for the Parent zone) is the Registry. The
> Registry is not necessarily the DNS operator ("entity responsible for running
> DNS servers", RFC9499), so "DNS operator" seems wrong to me here.
> 
> In other places in the document, DNS Operator is also used to refer to the
> manager of the child zone. This also seems wrong to me.
> 
> I note that the title of 9615 uses "Zone Operator" which seems right to me. I
> also note that the body of 9615 consistently uses "DNS Operator". It seems this
> ship may have sailed.

The "Child DNS Operator" language comes from RFC 7344 which started the CDS/CDNSKEY work. I believe it is best to stick to the established terminology.

This argument does not apply to "Parent (DNS Operator)". I've changed it to just

NEW
    Parent:  The operator responsible for a Parent zone and, thus,
...

> ```
>     2.  Parent-side entities (such as registries) SHOULD reduce a DS
>         record set's TTL to a value between 5–15 minutes when the set of
>         records is changed, and restore the normal TTL value at a later
>         occasion (but not before the previous DS RRset's TTL has
>         expired).
> ```
> 
> Why is the previous TTL relevant to deciding how long to wait?

The thinking is that, when the previous DS TTL has not yet expired, you may not have been able yet to observe failures from the new RRset as it might now have been used for DNSSEC validation. Once the DS TTL has expired and you've seen no issues, there's reasonable assurance all is fine, and the TTL reduction starts being superfluous.

As usual, that's rough guidance and there is no perfect time. However, if the DS TTL is 86400, it would not make much sense to set the TTL to 300 after a change, and then return to 86400 when the reduction was in effect for only an hour or so.

> ```
>     3.  Child DNS operators SHOULD be notified using a report query
>         [RFC9567] to the agent domain as described in Section 4 of
>         [RFC9859].
> ```
> 
> Does 9567 apply only in error cases, or also in success cases?

Notifications to the Child DNS operator are about error conditions only (see the paragraph starting with "For error conditions"). There are no situations described in the draft where the Child DNS Operator would be informed of a success. So, while RFC 9567 appears to only apply in error cases, that's not a restriction to this use case.

To remove the potential confusion, I've changed "notified using a report query" to "notified of errors using a report query" in the recommendation you quoted above.

>     thus being ignored.
> 
> I suggest "causing all of them to be ignored"

Thanks, done. (Without "all of", as that could be misread as affecting other children as well.)

> Section 5.2 lists "situations of particular interest" and "conditions worthy of
> being reported". Then, "justified to attempt communicating" is linked to
> "reportworthy cases". If this indeed is meant to refer to only cases 3 and 4, I
> recommend being more explicit than repeating the term "reportworthy cases". If
> it is supposed to refer to the entire set, repeating the term is confusing.

It's meant to refer to error conditions (cases 3 and 4) only, as those definitely are reportworthy, whereas successful operations (bootstrapping or disabling DNSSEC) are "only" interesting but don't require any follow-up.

Accordingly, I've clarified by replacing the repetition of "For these reportworthy cases" with "In these latter two cases" (and the two cases immediately precede that sentence). Thanks for catching the ambiguity!

> I only mention section 6 to point out how well-considered all the reasoning in
> it is. Very good work.

<3

The commit addressing your feedback is here: https://github.com/desec-io/draft-ietf-dnsop-ds-automation/commit/a1c9f3c0b11f8c96e4a7246fc958a59be182c2f7

Best,
Peter