> On 6 Sep 2025, at 17:19, John R Levine <[email protected]> wrote: > >>> 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. >>> --> >> >> Instead of "native" (C), please use "built-in". >> >> I have no suggestion for how to replace "traditional" (A and B). > > I think A and B are fine. They're referring to practice within the IETF and > DNS operations. I suppose you could change them to "existing" but that > wouldn't be as clear.
I also think that “traditional” is ok. But if we really should change it then my suggestion would be to change “traditional” into “original”. >> 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) > > 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. I think MUST is too strong and SHOULD is the right emphasis in this case. > Pending resolution of that last suggestion, I approve everything else. Same here. And thanks to the RFC-Editor team for the help with improving the document. Regards, Johan Stenstam Swedish Internet Foundation
smime.p7s
Description: S/MIME cryptographic signature
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
