On Tue, 9 Sep 2025, Sarah Tarrant wrote:
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.
That's OK.
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.
That's OK.
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
Read through it, and I approve.
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 <peter=40desec...@dmarc.ietf.org>
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, jo...@taugh.com, 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
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
