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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
