[Re-sending with co-author Steve Sheng's email address corrected. Not sure why
the original message went to his old address; the document actually has the
current one. -- Steve, can you respond whether you approve of publication after
the below fixes have been made? Thanks!]
Dear RFC Editor, Alanna and Sandy,
Thank you for the editing.
With the below addressed, I approve of this RFC for publication.
I've spotted the following things that I'd like to comment on.
#1 You changed
ORIGINAL
both the registrar and the registry can effect
CURRENT
both the registrar and the registry can affect
The intended meaning is in fact "effect" (bring about), not "affect"
(influence). Can this please be changed back?
#2 At "Readers are expected to be familiar with DNSSEC", please add RFC9975 (it
wasn't published at the time of writing, but is a central component of the document and
referenced in various places).
#3 At "records of DS automation decisions, including", you changed data elements (timestamp, decision
outcome) to plural. Let's keep singular, but change to "records of each DS automation decision, including".
Also, "DS RRset application" is not correct, so please change back to "applied DS RRset".
#4 "change in an SOA serial" is not correct. Please change back to "change in SOA serial", or
"change of SOA serial", or "SOA serial change".
#5 We received additional feedback that RFC9859 is mentioned in a few places
but is not properly tied into the recommendations, so the related guidance is
inappropriately disconnected. This is predominantly an editorial omission as
RFC9859 didn't exist at the time of writing. I've consulted with the
responsible AD for how to fix this, and we agreed on the following four
adjustments (which are expected to receive Med's approval):
## Section 4.1 and Appendix A.1
OLD
2. Parent-side entities (such as registries) SHOULD reduce a DS
record set's TTL to a value between 5-15 minutes when a new set
of records is published and restore the previous (or, if
unavailable, default) TTL value at a later occasion (but not
before the previous DS RRset's TTL has expired).
NEW
2. Parent-side entities (such as registries) SHOULD allow for
effective rollback by reducing a DS record set's TTL to a value
between 5-15 minutes when a new set of records is published, and
restore the previous (or, if unavailable, default) TTL value at a
later occasion (but not before the previous DS RRset's TTL has
expired).
Besides a prudent choice of TTL, prompt DS changes also require
timely discovery of update requests. For recommended methods,
see Section 4.2.2.
## Section 4.2.2 (changes title, adds a first paragraph)
OLD
4.2.2. TTLs and Caching
NEW
4.2.2. Timing, TTLs, and Caching
For timely execution of DS provisioning requests, it is important to
discover them reasonably quickly. The best way to do so is for the
Child DNS operators to send an RFC 9859 notification to the parent
(RFC 9859 Sections 4.1 and 4.2). In addition to publication of the
relevant notification targets, this requires the advertised endpoint
to actually listen (RFC 9859 Sections 3 and 4.3). By explicitly
naming a responsible endpoint, this method also resolves potential
contention between Registry and Registrar when the RRR model is used
(see Section 7.2.3). Note that periodic scanning is a suboptimal
alternative as it introduces policy-dependent delays and does not
scale well for large zones.
## Section 5.1 and Appendix A.2
OLD
3. Child DNS operators SHOULD be notified of errors using a report
query [RFC9567] to the agent domain as described in Section 4 of
[RFC9859]. Notifications to humans (domain holder) will be
performed in accordance with the communication preferences
established with the parent-side entity. The same condition
SHOULD NOT be reported unnecessarily frequently to the same
recipient.
NEW
3. Child DNS operators SHOULD be notified of errors using a report
query [RFC9567] to the agent domain as described in Section 4 of
[RFC9859]. Note that this requires listening to notifications
and that appropriate notification targets are in place (RFC 9859
Section 3).
Notifications to humans (domain holder) will be performed in
accordance with the communication preferences established with
the parent-side entity. The same condition SHOULD NOT be
reported unnecessarily frequently to the same recipient.
## Section 7.1 and Appendix A.4
OLD
the registry SHOULD publish the registrar's notification endpoint
[RFC9859] (if applicable) and refrain from registry-side DS
automation.
NEW
the registry SHOULD publish the registrar's notification endpoint
[RFC9859] (if applicable) instead of their own and refrain from
registry-side DS automation.
Other feedback below.
On 7/9/26 23:33, [email protected] wrote:
While reviewing this document during Final Review, please resolve (as necessary)
the following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
DNS
DS # in the title already, but in ()
2) <!--[rfced] Should the citation to Section 5 be updated to Section 5.1
to be more specific?
Original:
Any failures - such as a missing DNSKEY due to improper rollover timing
([RFC6781], Section 4.1), or changed algorithm requirements - can
then be communicated in line with Section 5, without altering or
removing the existing DS RRset.
-->
Sure.
3) <!--[rfced] Should instances of "DNSSEC security" be updated to read simply
"DNSSEC" to avoid redundancy (if expanded, "DNSSEC security" would read
"DNS Security security"). Please review and let us know if any updates are
needed.
Original:
... in non-technical language, such as
"DNSSEC security for your domain has been enabled and will be
maintained automatically"
...
DNSSEC security guarantees and associated
benefits are no longer in effect.
-->
No.
Rationale: Most people consider "DNSSEC" the proper noun of the technology. Consider a different technology,
e.g., VPN, where these would read "VPN security has been enabled" and "VPN security guarantees".
That's reasonable phrasing, and when people read "DNSSEC", they don't think of the expansion.
4) <!--[rfced] It's unclear how "further" fits into this sentence. May we
remove it?
Original:
DS automation by the registry further is consistent with Section 2.3
of [RFC5731], which explicitly notes that an EPP server (registry)
may override status values set by an EPP client (registrar), subject
to local server policies.
Perhaps:
DS automation by the registry is consistent with Section 2.3
of [RFC5731], which explicitly notes that an EPP server (registry)
may override status values set by an EPP client (registrar), subject
to local server policies.
-->
The section lists arguments for the technical recommendation, and this is a
"further" argument (in case a reason would have formulated the potential
related objection in their head). However, the word is not needed to make the point, so
I'll leave it to your editorial preference.
5) <!--[rfced] It is unclear how "either" fits into this sentence. May
we remove it?
Original:
However, it is not expected to be
harmful as either DS RRset will allow for the validation function to
continue to work, as ensured by Recommendation 1b of Section 4.
Perhaps:
However, it is not expected to be
harmful as the DS RRset will allow for the validation function to
continue to work, as ensured by Recommendation 1b of Section 4.
-->
The previous sentence talks about DS flapping: two different RRsets could be processed in an alternating
fashion. The section is about whether that is a problem. In the context at hand, both RRsets are functional,
so it is not a problem "either DS RRset works". Replacing "either" by "the" is
not correct.
Many reviewers have not flagged this as a problem, so I'd suggest to leave as
is, in particular as it's only part of the analysis and not normative. If you
feel strongly that this is very confusing, feel free to suggest an alternative
that better conveys the intended meaning (but again, I think it's fine).
6) <!--[rfced] Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
Parent vs. parent
Child vs. child
-->
Those all look fine.
7) <!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
DNS-Based Authentication of Named Entities (DANE)
-->
OK.
8) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
OK.
Best,
Peter
Thank you.
Alanna Paloma and Sandy Ginoza
RFC Production Center
On Jul 9, 2026, at 2:30 PM, [email protected] wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Final Review for RFC-to-be 10026 <draft-ietf-dnsop-ds-automation>
Your document is now available for Final Review (previously AUTH48). Once it
has been
reviewed and approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies;
see the Unavailable Authors section
(https://authors.ietf.org/rfc-publication-process#unavailable-authors).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using 'REPLY ALL' as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is an archival mailing list
to preserve discussion about the document while in the RPC editorial
queue; it is not an active discussion list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use 'REPLY ALL',
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc10026.xml
https://www.rfc-editor.org/authors/rfc10026.html
https://www.rfc-editor.org/authors/rfc10026.pdf
https://www.rfc-editor.org/authors/rfc10026.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc10026-diff.html
https://www.rfc-editor.org/authors/rfc10026-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc10026-xmldiff1.html
Tracking progress
-----------------
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc10026/
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 10026 (draft-ietf-dnsop-ds-automation)
Title : Operational Recommendations for DNSSEC Delegation Signer
(DS) Automation
Author(s) : Steve Sheng,
Peter Thomassen
WG Chair(s) : Benno Overeinder, Ondřej Surý
Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
