Hi Peter, John, Johan, 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 ------------------------------------------------------------- Peter, John, and Johan - Thank you for your replies. We have updated the document accordingly. We have one followup comment (A) and one followup question (B). (Please also see "clear record" below.) A) FYI, regarding: >>> 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. >>> In addition, please consider whether "traditional" and "native" should be >>> updated for clarity. While the NIST website >>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> >>> indicates that this term is potentially biased, it is also ambiguous. >>> These are subjective terms, as they may mean the same thing for everyone. >>> Note that updates of this nature typically result in more precise language, >>> which is helpful for readers. >>> Current A: >>> Traditional DNS notifications [RFC1996], which are here referred to >>> as "NOTIFY(SOA)", are sent from a primary server to a secondary >>> server, to minimize the latter's convergence time to a new version of >>> the zone. >>> Current B: >>> The basic idea was to augment >>> the traditional "pull" mechanism (a periodic SOA query) with a "push" >>> mechanism (a Notify) for a common case that was otherwise very >>> inefficient (due to either slow convergence or wasteful and overly >>> frequent scanning of the primary for changes). >>> Current C: >>> This >>> opens up the possibility of having an arbitrary party (e.g., a side- >>> car service) send the notifications, enabling this functionality even >>> before the emergence of native support in nameserver software. >>> --> >> >> Peter: >> >> Instead of "native" (C), please use "built-in". >> >> I have no suggestion for how to replace "traditional" (A and B). > > Johan: > > I also think that “traditional” is ok. But if we really should change it then > my suggestion would be to change “traditional” into “original”. We updated "native" to "built-in" and "traditional" to "original". Please verify. B) Regarding: >>>>>>> Peter: Section 4.2 >>>>>>> OLD (current, after RFC editing) >>>>>>> Therefore, it is RECOMMENDED that the child delay sending >>>>>>> notifications >>>>>>> NEW >>>>>>> Therefore, the child SHOULD delay sending notifications >>>>>>> >>>>>>> (Rationale: currently, one may read "child delay" as a noun) >>>>>> >>>>>> >>>>>> John: I would change the SHOULDs in 4.2 and 4.2.1 to MUST unless we can >>>>>> describe situations where interop would be better if you don't. >>>>> >>>>> Johan: I think MUST is too strong and SHOULD is the right emphasis in >>>>> this case. >>>> >>>> John: If MUST is too strong, when is it OK not to do that? We're telling >>>> people how to interoprate, what should they do? >>>> >>>> In 4.2 is it "unless the operator has external knowledge that the endpoint >>>> will scan soon"? In 4.2.1 I can't think of plausible situations where you >>>> would do something else. >>> >>> >>> Johan: It seems to me that we interpret the text differently. To me it is >>> about “MUST/SHOULD delay sending [until]” while it sounds like to read >>> “MUST/SHOULD send notification”. My problem is with the “[until]”. In the >>> end we obviously want the same thing: notifications being sent. >>> >>> Here is my reasoning, but I’m not a native English speaker, so I do not >>> claim any ultimate authority over a language issue like this: >>> >>> A MUST is absolute. Absolute directives should be reserved for when they >>> are (a) needed and (b) possible to ensure. >>> >>> In this case the text specifies that >>> >>> “...delay sending notifications to the recipient until a consistent public >>> view of the pertinent records is ensured”. >>> >>> That’s great. But what if, for reasons we don’t know here, whoever is >>> responsible for sending notifications is simply unable to verify that the >>> public view is consistent? Should the sender then NOT send the >>> notification? Or should it delay a reasonable amount of time before >>> sending? Or delay for a bit, then check again? How many times? Forever? >>> >>> As these are distributed systems with lots of parts and lots of stuff in >>> between the parts (that may and will break in all sorts of unpredictable >>> ways, according to Murphy’s Law) I think the right level of emphasis is to >>> clearly state how the system SHOULD act without getting entangled in the >>> exact semantics of all various possible failure modes. >>> >>> In the end, generalized notifications is an optimization of an underlying >>> mechanism. As such it is by definition “best effort”. Therefore, we accept >>> that it is possible that on occasion it will fail. To me, the combination >>> of “MUST” and “best effort” is, well, wrong :-) >> >> Peter: [...]> But what if, for reasons we don’t know here, whoever is >> responsible for sending notifications is simply unable to verify that the >> public view is consistent? Should the sender then NOT send the notification? >> Or should it delay a reasonable amount of time before sending? Or delay for >> a bit, then check again? How many times? Forever? >> >> I'm with Johan here. That's the reason for the SHOULD, because otherwise >> senders who don't know all the secondary locations (which is not a >> completely unreasonable scenarios when outsourcing secondaries) would >> effectively be precluded from ever sending a notification. >> >> So, I neither see a technical to change this away from what the WG consensus >> was, nor a different reason for why the discussion should be re-opened. > > John: We argued for a while and we agreed to leave the SHOULD and RECOMMENDED > as is in 4.2 and 4.2.1. Since it appears that the original goal was to avoid "child delay", perhaps changing the verb to subjunctive mood (adding "would" to show a possible/desired outcome that has not happened yet) would remedy the above discourse about "MUST/SHOULD". Note that I would also like to update "is ensured" to "could be ensured". 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. 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) 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 9, 2025, at 10:26 AM, Peter Thomassen > <[email protected]> wrote: > > Dear RFC Editor, > > With the below, I think there are no open discussions, and all approvals have > been collected. Please let the authors know in case you need anything else to > finalize editing. > > Feel free to send a final redline if you'd like me to cross-check AUTH48 > changes. > > Thanks, > Peter > > > On 9/9/25 16:28, John R Levine wrote: >> On Mon, 8 Sep 2025, John R Levine wrote: >>> On Mon, 8 Sep 2025, Johan Stenstam wrote: >>>>> I would change the SHOULDs in 4.2 and 4.2.1 to MUST unless we can >>>>> describe situations where interop would be better if you don't. >> We argued for a while and we agreed to leave the SHOULD and RECOMMENDED as >> is in 4.2 and 4.2.1. >> Regards, >> John Levine, [email protected], Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. https://jl.ly > > -- > 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]
