On Wed, 2025-03-05 at 15:36 +0100, Peter Thomassen wrote:
> > > It seems desirable to minimize the number of steps that the
> > > notification sender needs to figure out where to send the NOTIFY.
> >
> > This sentence needs work. "needs to /perform to/ figure out" perhaps?
>
> Done ("needs to perform in order to figure out").
>
> (Not really sure, why, though -- it's valid to say, e.g., "how many beers to you need to get tipsy", without adding "to drink" ...)
Not all language that is correct is also clear and understandable to the
average (often non-native) reader. See also the "results" thing below :)
> >
> > > If a positive DSYNC answer results,
> >
> > This appears to be legit English, but it is phrased uncommonly, causing
> > spurious reboots in human readers :-)
>
> I'm not sure what causes the mental reboot :) Do you have a suggestion for improvement?
Perhaps "If the result is a positive DSYNC answer," or closer to your
version "If this results in a positive DSYNC answer,".
> > 4.1 3, "parent zone labels" perhaps "parent zone label(s)" ?
>
> It's always at least two (because of the root label; of course unless the root zone decides to use this).
Ah, I tend to not count the root label explicitly. I consider
"example.com." to be two labels. RFC 4034 3.1.3 uses the same definition;
I do note that it explicitly mentions not counting the root label, which
makes me wonder if another definition (one that does count the root
label) is also common.
>
> > 4.2.1: i like the report-channel idea! Note that 9567 6.1 says "MUST NOT be
> > included in queries". Perhaps explicitly write down that you are making an
> > exception to that rule.
>
> Good point. It seems like it's unclear whether "MUST NOT be included in queries" applies to opcode 0 (Query) or to QR=0, independently of the opcode. As it is in RFC9567's section on "reporting resolvers", I'm inclined to think that NOTIFY messages are not intended to be covered.
Ah yes, there is a reading that puts NOTIFY out of scope here. I guess my
interpretation can indeed be noted as 'QR=0'.
> I have tentatively added:
>
> NEW
> [...] (The prohibition of this option in queries ([RFC9567],
> Section 6.1) only applies to resolver queries and thus does not cover
> NOTIFY message.)
>
> ... but I'm not sure if this is the best way to put it. Definitely open for other suggestions!
Would be great to get away with it like this :)
> > (And perhaps, 4.3 step 1 should be doing more than
> > flipping the QR bit - it should also remove the report-channel option. This
> > seems obvious so I wonder if we need to be explicit here.)
>
> NEW
> 1. Acknowledge receipt by sending a NOTIFY response as described in
> [RFC1996] Section 4.7 (identical to NOTIFY query, but with QR bit
> set and any EDNS0 Report-Channel options removed) [...]
Most EDNS options do not want to be mirrored in responses. I think -less-
explicit language is better here. Perhaps just remove the entire bit in
()
>
>
>
> As we're during the cut-off period for draft submission, I've put the above changes here: https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify/pull/40/commits
Oops, wrote all my responses above before I noticed this. I'll check in
with the PR later.
Cheers, Peter
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
