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.
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.
Pending resolution of that last suggestion, I approve everything else.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
