Hi Sarah,
On 9/9/25 17:38, Sarah Tarrant wrote:
Peter, John, and Johan - Thank you for your replies. We have updated the
document accordingly.
Thank you.
I noticed that the new example which we added in the end of Section 4.2.1 does not
explain where the "6" in the example qname comes from. Let's please amend as
follows:
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:
I have no other suggestions or corrections (see below for explicit statements).
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.
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.
OK with me.
For a clear record, please send approvals after viewing the document in its
current form.
I approve of the publication as described above.
Best,
Peter
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
