Thanks for the patience to work through this.

Thanks to Jiankang Yao for the ARTART review and to the authors for promptly addressing the concern raised with it.

I also support Andy's and Roman's feedback about the use of BCP14 keywords.

I would like to thank Donald E. for the SECDIR review.

As my only comment would be basically the same as Deb's comment about the security considerations - I will just say that I whole heartedly support her comments.

Thanks to Donald Eastlake for their secdir reviews.  

I'm making this a no obj ballot, but I would like it to be carefully considered. I'm happy to chat about it, if that makes it easier.

Classically for Security Considerations, one would reference a RFC (or I-D) that outlines the existing pitfalls and issues. Outside of the security area drafts, a normal draft doesn't put these considerations throughout the draft.  However, we are not opposed to this idea.  

In the author's response to the secdir review, the draft-ietf-dnsop-cds-consistency was mentioned as covering this concern.  Upon review, it appears that this draft is referenced in Sections 4.1, 4.2.1, 4.2.3 (and Appendix A.1, which I assume is merely informative).  This assumes that there are no security considerations for any of the other sections, such as Section 4.2.2, Section 5 (can notifications be spoofed?), Section 6 or Section 7.  Is this true?

It would be simpler (for both the authors and the readers), if the security considerations were all in one place.  The authors can reference the appropriate pre-existing RFC/I-D which keeps the current draft short and to the point, focused on the operational concerns.

# Éric Vyncke INT AD comments for draft-ietf-dnsop-ds-automation-08
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits.

Special thanks to Shumon Huque for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to James Gannon, the DNS directorate reviewer:
https://datatracker.ietf.org/doc/review-ietf-dnsop-ds-automation-06-dnsdir-telechat-gannon-2026-05-12/ (and I have read the email discussion)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Andy's DISCUSS

I second Andy Newton's DISCUSS point about the use of `SHOULD` vs. `MUST`. The sentence in section 3 is not enough IMHO `However, not following any requirements designated with the "SHOULD" key word will generally lead to undesirable effects of ambiguity and interoperability issues.`

The use of BCP14 is also questionable as it is not really about interoperation. E.g., section 4.2.2 contains `The reduction should be in effect at least for a couple of days` still providing guidance to the operators without the use of BCP14. Same for section 5.2, which has no BCP14 and still useful.

See also next issue.

### BCP status

Linked to Andy's DISCUSS, whether this document is BCP or 'informational' is also another question. Some BCP-like RFC (e.g., RFC 9099) are informational and do not rely on BCP14, only plain English "should".

Thanks to the authors and the WG for their work on this document. I have a couple of comments to offer.

1) This is provided as a comment instead of a DISCUSS since I am not familiar with this subject matter. I would request my fellow ADs and the authors/WG to cross-check.

Sec 6.1 says:
To secure ongoing operations, automated DS maintenance MUST NOT be suspended based on a registrar update lock alone (such as EPP status clientUpdateProhibited [RFC5731]).
When performed by the registry, automated DS maintenance MUST NOT be suspended based on a registry update lock alone (such as EPP status serverUpdateProhibited [RFC5731]).

Is this in sync with what is specified in RFC5731 (not just letter but also spirit)? Or does it overrule that specification in the context of DS operations? RFC5731 is an Internet Standard. I don't think this document updates that, but well ... just checking!

2) Given that this is a BCP, I would suggest to remove Appendix A to avoid duplication of the text. IMHO it is equally important for readers to go through the analysis that is accompanying the recommendations to grasp the full context. We have AI for summaries ;-)

Section 3, paragraph 0
>    The guidelines for deploying DS automation set out in this document
>    are meant to achieve more uniform treatment across suffixes —
>    minimizing user surprise and providing baseline safety and uniformity
>    of behavior.  They are also intended to prevent disruption of DNS and
>    DNSSEC functionality.  At a minimum, compliance with this RFC
>    requires support for both DNSSEC bootstrapping [RFC9615] and
>    subsequent updates [RFC7344], [RFC8078] under the implementation
>    guidance below.

The last sentence reads as a MUST-level compliance requirement but does 
not use BCP 14 language. If it is intended as normative, it should say 
"MUST support both…". If it is merely descriptive, the word "compliance" 
should be removed or rephrased. As written, it is ambiguous.

Section 10, paragraph 0
>    This document considers security aspects throughout, and has no
>    separate considerations.

The document's subject matter — automated, authenticated modification 
of DS records — has non-trivial threat surfaces that are dispersed 
through the body of the document but never consolidated into a threat 
model. At a minimum, the Security Considerations should address:

- Automated DS removal: Section 7 describes the conditions under which 
  DS records are automatically deleted. The security implications — 
  that a zone could be stripped of DNSSEC protection without the 
  registrant's direct action — is not called out as a threat.

- Authentication compromise:  If an attacker gains control of child 
  zone signing keys or nameservers, automated DS updates become an 
  attack vector. The checks in Section 4.1 partially mitigate this, 
  but the residual risk is not articulated.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 7.2.2, paragraph 4
>  DS update has occurred. * An exception from this rule is when the entire DS
>                               ^^^^^^^^^^^^^^
Did you mean "exception to"?

Section 7.2.2, paragraph 14
> considerations. The document's subject matter — automated, authenticated mod
>                                ^^^^^^^^^^^^^^
This phrase is redundant. Consider using "subject" to avoid wordiness.

# IESG review of draft-ietf-dnsop-ds-automation-06

CC @MikeBishop

## Comments

I support Andy's and Roman's feedback about the use of BCP14 keywords.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### URLs

These URLs in the document can probably be converted to HTTPS:

 * http://www.iana.org/assignments/ds-rr-types

### Grammar/style

#### Section 6.2.1, paragraph 3
```
y the registrar (or the registry) themself, such a lock is not suitable for
                                  ^^^^^^^^
```
Generally speaking, "themself" is only acceptable when referring to a singular
entity (such as the singular usage of "they", which is the preferred pronoun
for many non-binary people). If "themself" refers to a plural entity (such as
"everybody", or the standard usage of "they"), you should use "themselves".

If "the registrar" is being referenced impersonally, consider "itself."

#### Section 7.2.2, paragraph 4
```
 DS update has occurred. * An exception from this rule is when the entire DS
                              ^^^^^^^^^^^^^^
```
Did you mean "exception to"?

Thank you to Thomas Fossati for the GENART review.

Thank you for clarifying the normative language to improve interoperability.