Reviewer: Peter van Dijk Review result: Ready with Nits I am the assigned DNSDIR reviewer for this document. Generally this document appears to be in very good shape. I have several nits. Some of those I have phrased as questions below, but they really are requests to improve the text. My impression (without recalling previous revisions) is that the text has suffered a bit from evolving insights over time, without the necessary refactoring to put thoughts straight again. Nothing in this review prevents publication, but I think going through my notes below will make the document clearer and better. None of my suggestions, questions or comments imply functional changes to the meaning of the text. While the draft is called "generalized", 1.1 immediately dives into the parent/child synchronisation angle. I don't want to tell you to rework the document at this stage, but it seems quite specific when introduced like this. > 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? 2.3: I don't -think- you mean to say that NOTIFY(CDS) covers both CDS and CDNSKEY, but I am not certain. That bit of text could be clearer. (It turns out section 4 does clarify this.) > under the _dsync subdomain of the parent zone, as described in the following subsection I suspect "following subsection" was once true, but in -07, it's the next two subsections. Perhaps "in the rest of this section" or just "in this section" is clearer. > The scope for the publication mechanism is therefore wider than only > to support generalized notifications, and a unified approach that > works independently of the notification method is specified in this > section. This sentence derails itself around ", and a". Which thing is a unified approach? The publication mechanism? The scope of it? > It is RECOMMENDED to secure the corresponding zone with DNSSEC. Which zone is "the corresponding zone"? The one with the `_dsync` subdomain? (I'm pretty sure it is, but this could be written more clearly.) > If a positive DSYNC answer results, This appears to be legit English, but it is phrased uncommonly, causing spurious reboots in human readers :-) 4.1 3, "parent zone labels" perhaps "parent zone label(s)" ? 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. (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.) 4.2.2: I wonder if this will basically double zone sizes, which some TLDs may not like. However, I don't have a better idea. 4.3 option 1, "period scanning" -> periodic? 4.3 option 2, I wonder if REFUSED+Blocked as a -reply- makes sense, but that may conflict with the requirement "To prevent retries". The last sentence of 4.3 says "oh by the way this section is for CSYNC too". I suggest rewriting the first few sentences to de-specialise the text from CDS to both. 5: An unfinished thought: what if an attacker gets control over CDS/CDNSKEY in a zone, briefly (until detection, perhaps)? Having a NOTIFY mechanism would allow them to benefit from that small window, while scheduled checks would require a much larger attack window. A.1: s/replacing/augmenting/ ? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
