Hi John, Johan, Peter, and *Warren, *AD review - Warren - Regarding the following nit from Peter:
> Appendix A.2 > OLD (current, after RFC editing) > [DNSSEC-AUTO] > NEW > [RFC8901] > > (Rationale: the DNSSEC-AUTO draft was anticipated to be published before this > but was not; the currently correct informative reference therefore is RFC > 8901.) Please review the informative reference update and let us know if this change is approved: Removed: I-D.ietf-dnsop-dnssec-automation Replaced with: RFC 8901 (which was already an informative reference) Best viewed at: https://www.rfc-editor.org/authors/rfc9859-auth48diff.html https://www.rfc-editor.org/authors/rfc9859-auth48rfcdiff.html ------------------------------------------------------------- Peter, John, and Johan - Thank you for your replies. We have updated the document accordingly and have marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9589). We will await Warren's approval prior to moving this document forward in the publication process. The updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9859.txt https://www.rfc-editor.org/authors/rfc9859.pdf https://www.rfc-editor.org/authors/rfc9859.html https://www.rfc-editor.org/authors/rfc9859.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9859-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9859-auth48diff.html (AUTH48 changes only) Note that it may be necessary for you to refresh your browser to view the most recent version. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9859 Thank you, Sarah Tarrant RFC Production Center > On Sep 11, 2025, at 5:28 AM, Johan Stenstam > <[email protected]> wrote: > > Hi Sarah, > >> A) FYI, regarding: >> >> We updated "native" to "built-in" and "traditional" to "original". Please >> verify. > > I approve this change. > >> B) Regarding: >> >> Current: >> Therefore, it is RECOMMENDED that the child delay sending >> notifications to the recipient until a consistent public view of the >> pertinent records is ensured. >> >> Perhaps: >> Therefore, it is RECOMMENDED that the child would delay sending >> notifications to the recipient until a consistent public view of the >> pertinent records could be ensured. > > I approve this change. > >> Please review the document carefully to ensure satisfaction as we do not >> make changes once it has been published as an RFC. >> >> For a clear record, please send approvals after viewing the document in its >> current form. >> >> The updated files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9859.txt >> https://www.rfc-editor.org/authors/rfc9859.pdf >> https://www.rfc-editor.org/authors/rfc9859.html >> https://www.rfc-editor.org/authors/rfc9859.xml >> >> The relevant diff files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9859-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9859-auth48diff.html (AUTH48 changes >> only) > > I have reviewed the entire updated document and have no objections. That > said, I do agree > with Peter that his suggested change would be an improvement (but it is not a > show-stopper): > >> CURRENT >> For example, when receiving a NOTIFY(CDS) message for "example.com" >> with agent domain "errors.ns1.example.net", and when the requested DS >> update is found to break the delegation, then the following report >> query may be made (preferably over TCP): >> >> NEW >> For example, when receiving a NOTIFY(CDS) message for "example.com" >> with agent domain "errors.ns1.example.net", and when the requested DS >> update is found to break the delegation, then the following report >> query with EDE code 6 (DNSSEC Bogus) may be made, preferably over TCP: > > Regards, > Johan Stenstam > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
